This topic details the configuration necessary to enable SAML SSO for customer with a need to create a single sign on environment.
See the topic Configure SAML Single Sign On for specific direction in configuring Single Sign On implementation for authentication.
Single Sign-On Background
SSO Allows users to a have a single login for multiple applications.
Users are typically not pre-created in BuyerQuest.
User do not store passwords in BuyerQuest. Passwords are controlled via an external application from the Identity Provider, known as an IDP.
Access to BuyerQuest is controlled by the client.
Users do not see a login screen when connecting if they are already logged in through SSO.
Glossary of Terms
Acronym for Single Sign-On
Security Assertion Markup Language - one type of SSO that is used.
Sometimes referred to as SP, and provides organizations with services such as processing or storage. A service provider can be within the organization or outsourced.
Sometimes referred to as IDP, is a system function that creates, maintains, and manages identity information with authentication services to applications relying on it within a federated or distributed network.
Metadata is basic information needed by the service provider, IDP, and client that is used for SSO authentication usually including the list of methods, location information and configuration information necessary to allow logins.
Single Sign-On Configuration
Sequence of Steps in Configuration
- Get the IDP metadata URL from the customer - see below for explanation of purpose and contained data
- Provide the customer the link to the BuyerQuest Metadata file - typically at <site>/simplesaml/module.php/saml/sp/metadata.php/saml
- This file is required to be added by the customer to make BuyerQuest a service provider.
- Provide a link to the client for UAT and Production environments
- Map and configure the metadata attributes - See: 1.2 Administration
- Bad link above -- delete this or find it in the wiki. Remove this comment style for this list.
- Get test accounts from customer to test connectivity
Single Sign-On is configured in the Admin Control Panel at System Administration > Settings and Configurations > Manage System Configurations > System Management > SAML SSO.
Change all the screenshots and review all the verbiage.
Ask Brian or Alex to review this document.
|1||WebSSO Claims Logging||When enabled logs incoming claims data to the local file system. This is useful in mapping incoming data to attributes||Should always be disabled in production environments to prevent filling of logs|
|2||Enable SAML SSO||Master switch to enable or disable SAML authentication|
|3||Require Login||Always = "No" other modules prevent non-logged in users|
|4||Identify Provider MetaData URL||This URL is the location of the metadata that is provided by the identity provider. This metadata provides a mapping of all available fields and is retrieved from the identity provider each time the cache value is reached.||This URL can be visited manually in a browser to see the metadata XML for a site.|
|5||Minutes to Cache||This value specifies the amount of time to cache the meta data information in minutes. This value is set low during development especially if the provider is making changes to their SSO configuration on the identity provider side. Recommended Production Value: 10080 (one week)|
|6||CRT Data||This is the certificate of the client. This value is only used if the identity provider does not provide keys which most do|
|7||Allow SSO to create new customer||Allow SSO module to create new users. Typically set = Yes but could be = No if the client is feeding all customers via master data exchange and does not want new users that do not come from the data feed.|
|8||Redirect to CMS||Always set to No||Custom solution for non registered in place|
|9||Select CMS||Not required|
|10||Add address from clam information||Always set to No|
|11||Custom Mappings||This section provides a mapping between user attributes and SSO data. When selected the attribute value is set via the data provided in the SSO metadata. This section is configured to contain customer specific attributes as required. Standard Mappings:
|12||Field that Magento is using as identity field||Attribute used by the system to identify the user. This value must be unique for each user.|
|13||WebSSO Login||This is the path to the login code. This should not be changed|
|14||SAML field to use as ID in generated email||In scenarios where email addresses are shared the system needs a unique "email" for each user. In this case the value of ID is mapped with a dummy email address suffix to create a unique email.|
|15||WebSSO Logout||This is the patch to the logout code. This should not be changed|
|16||Split a composite first / last name||If the identity provider gives the first and last name in one field this option can split into first and last name. IE "John Doe" becomes "John" and "Doe"|
|17||Split schema mapping||Location of composite name in metadata.|
Setting Attributes for Single Sign On Mapping
In order to map the value of a user attribute to a SSO value you need to enable SSO mapping of that attribute in the user attribute configuration
Configuration Link: index.php/control/customer_attribute/
The simplesaml php module contains its own administration pages that can be used to verify the data in the module.
Configuration Link: /simplesaml/module.php/core/frontpage_federation.php
|1||SAML 2.0 SP MetaData||Location of BuyerQuest Metadata file. This link is provided to the customer|
|2||SAML 2.0 IDP MetaData||Identity provider URL, this value is retrieved by the link to the client federation metadata on a scheduled bases determined by the configuration and cache lifetime - See 1.2 Administration|
Source: Community Module (Modified)