Discussion
Pegasystems Inc.
US
Last activity: 1 Sep 2023 16:40 EDT
Ask the Expert - SAML Authentication with Lakshmi Billa and Anupam Dubey
Join @LakshmiBilla and @Anupam Dubey as they answer your questions about SAML Authentication!
Make sure to Favorite and Follow for updates via the Notification bell and/or weekly digest!
Session dates: 21 August - 1 September
Session opens to questions on the 21st of August!
Meet Your Experts, Lakshmi Billa and Anupam Dubey:
I am Lakshmi BIlla, Principal Software Engineer, with 12 years of experience, 9 of those working here at Pegasystems! I am on the Application Security Tribe working on the Authentication and Authorization module. I also work on OAuth2, SAML (Security Assertion Markup Language), OIDC (OpenID Connect), RBAC (Role Based Access Control), ABAC (Attribute Based Access Control), CBAC (Client Based Access Control), encryption, user management, RSA (Rule Security Analyzer), mitigation of OWASP Top 10 vulnerabilities etc.
I'm Anupam Dubey, and I have a strong background in providing dedicated support to clients as part of Global Client Support at Pega. Over the years, I've had the opportunity to collaborate with clients from around the world, assisting them in resolving a wide range of issues and providing effective solutions. My expertise lies in application security, where I have worked closely with clients to identify and address security vulnerabilities, ensuring their systems adhere to industry standards.
Message From Your Experts, Lakshmi Billa and Anupam Dubey:
We are participating for the first time in the Ask the Expert series on the Support Center and are very excited about answering questions related to SAML 2.0. We really hope that we can help our clients, partners and Pega as a whole to understand SAML Authentication!
Ask the Expert Rules
- Follow the Pega Support Center's Rules of Engagement
- This is not a Live Chat - @LakshmiBilla and @Anupam Dubey will reply to your questions over the course of the session
- Questions should be clearly and succinctly expressed
- Questions should be of interest to many others in the audience
- Have fun!
-
Likes (4)
Anil RDV Mateusz Kostolowski Bhargavi Siripurapu Sabry Ashroff -
Share this page Facebook Twitter LinkedIn Email Copying... Copied!
Pegasystems Inc.
IN
The Evolution Story of SAML: Problem Statement:
In our daily tasks, we often find ourselves using multiple applications, each demanding its own authentication. This necessitates managing and recalling distinct sets of credentials for every application. As time goes by, the burden of remembering numerous passwords becomes cumbersome and challenging. Furthermore, diverse password policies across applications contribute to a sub optimal user experience.
Solution:
The solution lies in instituting a unified sign-on process for all these applications.
Approach:
All the applications establish trust with a centralized identity provider. This identity provider assumes responsibility for verifying credentials and furnishing the applications with pertinent user information. By doing so, users only need to authenticate themselves once, granting them access to all linked applications without the need for multiple credentials.
This approach streamlines authentication, elevates user experience, and alleviates the intricacies associated with managing multiple passwords and diverse password policies across various applications.
-
Sabry Ashroff Saleem Shaik
Pegasystems Inc.
IN
Different parties involved in SAML flow:
Identity Provider(IDP): The authorization server which takes care of authenticating users by challenging the credentials.
It validates the user credentials.
If credentials are valid then it provides the SAML assertion to the Service provider.
Service Provider(SP): The application which trusts IDP to authenticate user.
It allows user to use application resources based on the SAML assertion provided by IDP.
SAML assertion: XML document which combines the statements of a user.
Bindings: The SP and IDP communicate with each other by using SAML messages.
Different parties involved in SAML flow:
Identity Provider(IDP): The authorization server which takes care of authenticating users by challenging the credentials.
It validates the user credentials.
If credentials are valid then it provides the SAML assertion to the Service provider.
Service Provider(SP): The application which trusts IDP to authenticate user.
It allows user to use application resources based on the SAML assertion provided by IDP.
SAML assertion: XML document which combines the statements of a user.
Bindings: The SP and IDP communicate with each other by using SAML messages.
The bindings define how these messages are transported.
Metadata: Both SP and IDP publishes their metadata.
The metadata contains the endpoint URLs, bindings , public keys etc.
-
NareshBabu Pottipati Sabry Ashroff
Pegasystems Inc.
IN
SAML2.0 protocols:
-
Sabry Ashroff
Updated: 28 Aug 2023 14:32 EDT
Pegasystems Inc.
IN
Please go through the below Pega documentation related to the SAML feature to get a quick understanding of SAML Authentication in Pega.
-
Sabry Ashroff
Pegasystems Inc.
IN
Protocol Binding
HTTP-POST
HTTP-Redirect
HTTP-Artifact
-
Anil RDV Yoke Wei Yip Sabry Ashroff
Pegasystems Inc.
IN
Runtime Flow for SP Initiated Login:
SAML Payload sent from SP to IDP:
- The SAML payload sent to IDP contains two elements enclosed in the request, the SAMLRequest and the RelayState.
- SAMLRequest is base64 encoded and contains the Issuer details and authentication request.
- The relay state ID is a unique ID (GUID) and points to a database record in Data-Admin-LoginInfo.
SAML Payload sent from IDP to ACS(SP):
- The IDP responds back to the AssertionConsumerService location of Pega with two elements which are the SAMLResponse XML and the RelayState.
- The SAMLResponse is Base64 and then URLEncoded and the relay state ID must be the same value that was sent as part of the request.
- The SAML Response can be decoded using any of the online tools like https://www.samltool.com/decode.php
- The response would contain the status code of the response, subject element, subject confirmation element, and the attribute statements.
- The attribute statements provided in the SAML response can be used to map to the Pega properties from the Mapping tab in the authentication service ruleform.
Runtime Flow of IDP Initiated Login:
SAML Payload sent from IDP to ACS(SP):
Runtime Flow for SP Initiated Login:
SAML Payload sent from SP to IDP:
- The SAML payload sent to IDP contains two elements enclosed in the request, the SAMLRequest and the RelayState.
- SAMLRequest is base64 encoded and contains the Issuer details and authentication request.
- The relay state ID is a unique ID (GUID) and points to a database record in Data-Admin-LoginInfo.
SAML Payload sent from IDP to ACS(SP):
- The IDP responds back to the AssertionConsumerService location of Pega with two elements which are the SAMLResponse XML and the RelayState.
- The SAMLResponse is Base64 and then URLEncoded and the relay state ID must be the same value that was sent as part of the request.
- The SAML Response can be decoded using any of the online tools like https://www.samltool.com/decode.php
- The response would contain the status code of the response, subject element, subject confirmation element, and the attribute statements.
- The attribute statements provided in the SAML response can be used to map to the Pega properties from the Mapping tab in the authentication service ruleform.
Runtime Flow of IDP Initiated Login:
SAML Payload sent from IDP to ACS(SP):
- The IDP sends two elements with the response, the SAMLResponse XML and the RelayState.
- The SAML response is base64encoded and then URL encoded by the IDP, just like in SP-initiated login.
- In this scenario, the relay state ID sent by the IDP is a URL(which is usually the SSO URL) instead of the GUID.
- The SAML response would contain the same data as mentioned in the SP Initiated Login.
-
Sabry Ashroff
Pegasystems Inc.
IN
Request/Response Assertion Signing:
Signing the SAML Request:
- To sign the SAML request, the SP uses its private key to create a digital signature of the entire SAML request message.
Signature Verification:
- Upon receiving the SAML request, the IDP uses the SP's public key to verify the digital signature. If the signature is valid, it confirms that the request was indeed sent by the legitimate SP, and the message has not been tampered with in transit.
- The successful verification of the signature establishes trust between the IdP and the SP. The IdP can then proceed to process the SAML request, perform user authentication, and generate SAML assertions for the user.
Assertion Encryption:
Request/Response Assertion Signing:
Signing the SAML Request:
- To sign the SAML request, the SP uses its private key to create a digital signature of the entire SAML request message.
Signature Verification:
- Upon receiving the SAML request, the IDP uses the SP's public key to verify the digital signature. If the signature is valid, it confirms that the request was indeed sent by the legitimate SP, and the message has not been tampered with in transit.
- The successful verification of the signature establishes trust between the IdP and the SP. The IdP can then proceed to process the SAML request, perform user authentication, and generate SAML assertions for the user.
Assertion Encryption:
- When a user successfully authenticates with an identity provider (IdP), it generates a SAML assertion containing information about the user's identity and attributes. This assertion is digitally signed to ensure its integrity.
- The SAML assertion may contain sensitive information, such as the user's email address, roles, or other attributes.
- To protect this sensitive information, the IdP can choose to encrypt the content of the SAML assertion.
- The IDP can use the public key provided by the SP to encrypt the assertion, and Pega(SP) can use its private key(which needs to be configured in the Auth service rule) to decrypt the assertion while processing.
To get more understanding of how the SAML AuthNRequest, SAML Response, Logout Request, or Logout Response would look like, please explore the examples stated in the link below.
https://www.samltool.com/generic_sso_req.php
-
Sabry Ashroff
Updated: 1 Sep 2023 12:37 EDT
Pegasystems Inc.
IN
Data Pages populated during SAML flow:
a) D_SamlSsoLoginInfo - It stores the SAML assertion received from IDP in string format.
b) D_SAMLAssertionDataPage - Assertion is parsed and populated to property values.
c) D_pzSSOAttributes - Stores the attribute values for configured attributes in the rule form.
-
Sabry Ashroff
Pegasystems Inc.
US
Thank you everyone for checking out our Ask the Expert on SAML Authentication with @LakshmiBilla and @Anupam Dubey!
And thank you Lakshmi and Anupam for being our experts and sharing your knowledge!
if you have any questions on SAML Authentication, please post a new question and our subject matter experts will help you!
Keep an eye on our Ask the Expert homepage for our upcoming sessions!