Before getting started with your SSO setup you need to have applied a custom binding (URL) to your storefront. For example www.mystorefront.com, as opposed to www.companyname.infigosoftware.com/storefrontname (this is the default binding on a new store).
For more information on the new binding and SSL process please see our other help centre articles:
What is Single Sign On?
Single sign-on is an authentication scheme that allows a user to log in with a single ID to any of several related, yet independent, software systems. True single sign-on allows the user to log in once and access services without re-entering authentication factors.
Security Assertion Markup Language 2.0 (SAML 2.0) is a version of the SAML standard for exchanging authentication and authorisation identities between security domains. Its an XML-based protocol that uses security tokens to pass information about a user between an Identity Provider (the third party system) and a Service Provider (your Infigo storefront).
SAML 2.0 enables web-based, cross-domain single sign on (SSO), which helps reduce the administrative overhead of distributing multiple logins for different systems to all of your users.
Overview
If you are wanting to direct end users from a centralised third party system into your Infigo storefront using Single Sign On (making the experience as fluid and simple as possible for your end users / customers) then our SAML 2.0 module might be the answer.
Our SSO module requires SAML 2.0 support from the third party system, so you would need to check with the administrators first. It also requires that third party system to be the Identity Provider (Infigo is the Service Provider).
Setup
The process of setting up the module is detailed below and can be found by searching "SAML" in the admin menu. NOTE: The SAML module is a paid module so will require a ticket to be raised with our support team before using.
Please do not be too overwhelmed by the technical nature of setting up the SAML module, our skilled support team are here to hold your hand every step of the way.
Step 1) Please submit a "Single Sign On" support ticket. Is is important that all fields are completed.
| The Identity Provider's Meta Data XML |
If you contact the company / team / person that manages the administration of SSO then they will understand this request and provide you with a file or a dynamic URL.
If you can provide us with a URL, then the setup process will be easier and it futureproofs any changes that are made in the SSO IDP. For example if an attribute name was changed then this would dynamically update. Whereas if we have a file, this would need to be sent to us to update manually. |
| Confirm how the user will be authenticated |
The authentication of a user can be done by either their email address or username, the decision on which to use is generally decided by the content of the IDP XML provided in step one but can be discussed during setup as this will require some additional Infigo Customer settings to be made also. If a user's email address was to change at any point (for example they marry and change their surname), then the user authentication via email address would no longer work. |
| Complete the attribute mapping table |
Scroll down a little to "Passing additional Information". Please copy and paste this table into the ticket or a word document, and give us the attribute mapping details. If you contact the company / team / person that manages the administration of SSO then they will understand this request and provide you with attribute names. |
|
Test user credentials |
We must have a test user. If we don't we cannot start the SSO setup. Please ask the team / person that manages the administration of SSO to create an account so we can test the connection. |
|
We cannot configure single sign on without all of the above. The setup will not be started until we have all of the aforementioned information. |
|
Step 2) Infigo will configure SSO (within Infigo Admin).
Once we have the Identity Provider's Meta Data XML and the authentication details will use this information to setup the SAML configuration XML on our side. We will use the test user provided to test the connection.
PLEASE NOTE: once the SAML setup has been done by Infigo and the metadata link has been provided by the Infigo support team, your site won't be accessible using the normal login page / URL. You will need to add "/login?originalCatfish=true" to the end of the site's URL to redirect around the SSO / SAML configuration until you have setup the metadata on your IDP.
Step 4) Metadata to be added to the SSO application.
We will provide a URL containing our SAML metadata that you will need to share with your third party system administrators (person / team managing the SSO administration). This contains an XML with the necessary data to establish a connection between the two systems.
Step 5) URL Redirect Configuration
We will setup the URL redirects for logging in (to the third part system credentials pages) and logging out (where you want the customer to be sent once they log out of Infigo).
We support two "versions" of SSO through SAML, the default is that end user will put the URL in their browser for the Infigo site and be redirected to the third party system to login (where they will use their normal centralised login credentials). Once successful they will be redirected straight back to Infigo and be automatically logged in with their account.
The second is that the end user doesn't really know the Infigo site URL and instead originates from the third party system. They log in to that third party system and then from within there they are show a link to access the Infigo site and are seamlessly logged in.
Both approaches are fine and supported, they just require some configuration adjustments on both ends.
As mentioned, if possible, it would be hugely beneficial for both the setup process and supporting the module moving forwards if we were provided with our own third party system login (a test user) so that we can test and troubleshooting the SSO process directly.
Passing additional Information
Although SAML 2.0 is a module to authenticate and authorise users, we also support now passing additional customer information from the third party system within the SAML request. This way you can ensure that when customer details change in the third party system they can also then be updated in your Infigo site too the next time the customer logs in through SAML.
These fields all need to be passed as SAML attributes. The names of the SAML attributes can all be mapped within our Module and will be done by our support team as part of the setup.
Please ask the company / team / person that manages the administration of SSO to provide the attribute mapping names, so we can set this up.
Below is a list of all the customer information we allow to be passed as part of the SAML request. Please copy and paste this table (or complete the attached word document at the bottom of this article) into the support ticket once you have the attribute mapping details.
| Infigo Attribute | SAML / SSO Attribute Mapping details |
| Title | |
| First name | |
| Last name | |
| Company | |
| Address 1 | |
| Address 2 | |
| Town/City | |
| Region | |
| ZipPostalCode | |
| Phone | |
| Fax | |
| Custom 1 | |
| Custom 2 | |
| Custom 3 | |
As part of this configuration, we also allow for you to decide which of the additional information should be done once (when the customer first logs in and a customer is created in Infigo for them) or every time they login (when there is information that you want to ensure stays up-to-date from the third party system)
Assigning customers to a Department or Customer Role
Lastly, we also support automatically assigning customers to either a Department or a list of Customer Roles.
We understand that in many scenarios you will want to provide different levels of access to different customers that are logged in or created from the third party system through SAML. Therefore, as an additional SAML attribute passed in the request XML we can setup mapping to add that customer to either a single department (either by Name or our Infigo Department ID) or to a number of Customer Roles (a comma delimited list of Customer Roles Names)
Then all you need to do is have all the Access Permission rules setup against all of those Departments or Customer Roles prior and the user will adopt those when they are added on registration or next login.
*Note - we can only accept one user group from your IDP. If you need to pass more then one, they need to be sent from one attribute, comma separated.
0 Comments