This module is utilized whenever customers have SAML SSO enabled and would like to create a single sign on environment.
Notes on using 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, their password is controlled via an external application (IDP)
Access to BuyerQuest, active/inactive users, etc are controlled by the customer
Users do not see a login screen when connecting if they are already logged in to their SSO
Glossary of Terms
|Identity Provider||http://en.wikipedia.org/wiki/Identity_provider - sometimes referred to as IDP|
Files that contain summary (meta) data about the SP or IDP. There will be a metadata file provided by the customer and a metadata file that is provided by BuyerQuest
Customer Meta Data: Contains the list of methods and the information that will be provided for each user when they authenticate via SSO
BuyerQuest Meta Data: Contains the location of the site, configuration for login, etc for the customer
|SAML||Security Assertion Markup Language - one type of SSO that is used. Find more on additional types here: http://en.wikipedia.org/wiki/Single_sign-on|
|Service Provider||http://en.wikipedia.org/wiki/Service_provider - sometimes referred to as SP|
|SSO||Acronym for Single Sign On|
Steps to configure:
- 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 link to the client for UAT and Production environments
- Map and configure the metadata attributes - See: 1.2 Administration
- Get test accounts from customer to test connectivity
SSO is configured in the Admin Control Panel at "Menu > System Administration > Settings and Configurations > Manage System Configuration > System Management > SAML SSO".
|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|
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.
See section Setting attributes for SSO Mapping
|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 SSO 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)