Salesforce Single Sign on Flows | Identity Flows : Amit Chaudhary
by: Amit Chaudhary
blow post content copied from Apex Hours
click here to view original post
Single Sign On (SSO) flows enable users to authenticate using their identity from an external system. There are three mechanisms which can be used to achieve this in Salesforce.
1) Delegated authentication
Using delegated authentication, Force.com does not validate passwords but instead uses an external Web service to validate user credentials. When a user attempts to login, the platform checks the user’s profile to see if they are enabled for SSO. If so, it makes a Web services call to the the endpoint specified for the organization (environment), asking it to validate the username and password. The Web services checks the credentials against an identity store (for example LDAP or OpenID) and either returns “true” or “false”. If true, the user is granted access to the application and proceeds normally. If false, the user is informed that their credentials are invalid.
2) Federated Authentication
As with delegated authentication, federated authentication does not validate the user’s actual password on the Force.com platform either. Instead, the platform receives a SAML assertion in an HTTP POST request. The SAML assertion has a limited validity period, contains a unique identifier, and is digitally signed. If the assertion is still within its validity period, has an identifier that has not been used before, and has a valid signature from a trusted identity provider, the user is granted access to the application. If the assertion fails validation for any reason, the user is informed that their credentials are invalid. The rest of this article shows how to set this up.
3) OpenID Connect
This leverages OAuth web server or user agent flows to establish trust. OpenId Connect authenticate users without having to get your hands dirty with passwords. Consume OpenID Connect from popular Identity providers with Social Sign-On. Provide a single, branded Identity to your own users and applications using OpenID Connect.
We’ll look at steps and considerations for the following single sign mechanisms:
- SAML Service Provider Initiated SSO
- SAML Identity Provider Initiated SSO
- OpenID Connect (Social Sign On)
- Delegated Authentication
Intended audience: Architects, developers, security professionals and identity buffs
For each flow we’ll cover:
- Sequence of steps
- Interesting characteristics
- Implementation considerations and trade-offs
Please check above blog post for recording link.
Single Sign On
What’s single sign on and why’s it so great?
What’s single sign on and why’s it so great?
Why SSO
- Consolidated security
- Reduce need to synchronize directories
- Easy Account Deactivate
- User love it
Decision guide
Please all session recording here before check below session. Check below recording to understand which flow we should use and when
2 Necessary fallback choice when iframing of canvas app login page not possible
3 Only when supporting SAML / OpenID Connect not practical
TERMINOLOGY
Lets check some terminology used in SSO.
SAML
- Security Assertion Markup Language (SAML) – Provides an open standard for XML-based confirmation of identity and transfer of identity attributes between an Identity Provider and Service Provider
- Identity Provider (IDP) – An application with the capability to authenticate a user’s identity (i.e. allow the user to login), and confirm authentication and identity attributes to a Service Provider
- Service Provider (SP) – An application which defers to an Identity Provider for authentication of a user, and allows this user access to protected resources or capabilities based on this authentication
- SAML Assertion – The portion of the SAML Response which confirms identity attributes of the authenticated user.
- SAML Request – The structured XML message sent by the Service Provider to an Identity Provider, identifying itself and requesting authentication of the user.
- SAML Response – The XML message sent by the Identity Provider to the Service Provider identifying itself as the issuer, indicating the status of the authentication attempt, and including the SAML Assertion if this can be issued (typically signed with the Identity Provider’s certificate).
OPENID CONNECT
- OpenID Connect (OIDC) – An identity extension to the OAuth 2.0 framework which specifies a JSON Web Token structure for confirmation of identity and communication of identity attributes
- OpenID Connect Provider (OP) – The application with the ability to authenticate a user and confirm identity attributes and authentication event information to a Relying Party. This application is playing the role of Authorisation Server in the terminology of OAuth 2.0
- Relying Party (RP) – The application deferring to the OpenID Connect Provider for an end user’s authentication and authorisation, and providing an authenticated service to the user once identity and authorisation is confirmed. This application is playing the role of Client in the terminology of OAuth 2.0
- ID Token – The JSON Web Token (JWT) structure used to communicate identity attributes from the OpenID Connect Provider to the Relying Party
- UserInfo Endpoint – Protected resource at the OpenID Connect Provider which will validate an access token and return authorised information about the user this token relates to
Further learning
NOTE: This is not a summary of certification content but general best practice, and independent from official Salesforce recommendations.
The post Salesforce Single Sign on Flows | Identity Flows appeared first on Apex Hours.
February 19, 2021 at 05:31PM
Click here for more details...
=============================
The original post is available in Apex Hours by Amit Chaudhary
this post has been published as it is through automation. Automation script brings all the top bloggers post under a single umbrella.
The purpose of this blog, Follow the top Salesforce bloggers and collect all blogs in a single place through automation.
============================
Post a Comment