Skip to main content
Buyerquest Community

Single Sign On (SAML SSO) Configuration

The SAML 2.0 module adds single sign on support to BuyerQuest using the SimpleSAML PHP module.


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

Term Definition
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:
Service Provider - sometimes referred to as SP
SSO Acronym for Single Sign On


Steps to configure:

  1. Get the IDP metadata URL from the customer - see below for explanation of purpose and contained data
  2. 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. 
  3. Provide link to the client for UAT and Production environments
  4. Map and configure the metadata attributes - See: 1.2 Administration
  5. Get test accounts from customer to test connectivity

Configuration Overview:

SSO is configured in the Admin Control Panel at "Menu > System Administration > Settings and Configurations > Manage System Configuration > System Management > SAML SSO".


ID Value Description Notes
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:

  • Name
  • Email
  • Role (if available)

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

Password: y6u7i8o9p0

ID Value Description Notes
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

Technical Notes

Source: Community Module (Modified)

Module Directories:

  • /app/code/local/Wizkunde/WebSSO
  • /lib/simplesamlphp