single sign on (SSO)
===================
User just remember one username and password that will allow us to logon to all other different applications.
It's like having a magic key that automatically opens up all the other doors once you enter through one door.
Salesforce provides different options to configure single sign on.
1.Federated Authentication using SAML
2.Delegated Authentication
3.OpenID Connect
Main concepts in SSO
1.The concept of IDP/SP
2.The Concept of IDP Initiated login and SP initiated login.
IDP stands for Indentity provider and SP stands for service provider.
In IDP Init SSO the Federation process is initiated by the IDP sending an SAML Response to the SP.
In SP-Init, the SP generates an AuthRequest that is sent to the IDP as the first step in the Federation process and the IDP then responds with the SAML Response.
IDP initiated Login :
=====================
User can logon to IDP and then from there, clicks on links to access other systems(i.e SP).This is called IDP initiated login.
user ----> Identity provider
|
|
| SAMl Assertion
V
salesforce (SP)
SP Initiated Login :
=====================
User can go directly to an SP application to access the application.
In this case, SP will redirect the user toIDP login page where user will provider
his/her username and password, IDP will authenticate the user and pass control
back to SP asserting whether user is authenticated or not.SP will then allow
user to access the application.
Note : Identity provider is the instance where users have an active session.
And service provider is the one which identifies the certificate from
the identity provider saying the user is coming from the authenticated source.
saml Auth Request
user ----> salesforce (sp) ------>
<------- Identity provider
saml assertion
Federated Authentication using SAML :
=====================================
1.Federated authentication uses SAML, an industry standard for secure integrations.Investing in SAML with Salesforce.com
2.org-wise level
3.Salesforce admins can enable.
Authentication and authorization between two entities : service provider and identity provider
The service provider agrees to trust the identity provider to authenticate users.
Note :
SAML stands for security Assertion Markup Language.
SAML is an XML-based protocol for exchanging identity and authorization information.
The SAML,which is basically XML documents that are going to be exchanged. Some are going to be exchanged at setup time, and some are going to be exchnaged when you try to
login.
That XML has a packet of information that contains authentication information, but it's built into that XML data model essentially.
Just-in-time user Provisioning :
============================
The just-in-time provisioning is basically the idp has the authority to create or update user information inside of the service provider.
relay :
========
SP init does it carries your original destination that you were trying to get to as part of the relay state.
The RelayState is meant to direct the user after a successful login to a specific location in the application they're logging into. If you need to include query parameters,make sure they're URL encoded.
RelayState=var1%3Dvalue1%26var2%3Dvalue2
SAML Assertion Validator :
===========================
1. Available in single sign-on settings.
2. used to check for failed logins of sso.
Delegated Authentication Flow :
===============================
Delegated Authentication is specific to salesforce only(not industry standard)
where external webservice only retruns "TRUE" and "FALSE" saying Authentication is complete
or not.
1.Require salesforce support to enable.
2.Permission level.
Note:
when the user submits the login page with their credentials, Salesforce look up the user from the username.If Delegated Authentication(DA) is configured for this org and user,
we send the supplied password to the configured Delegated Authentication (DA)
endpoint for verification,otherwise we verify the password against the hash
we have on record for that user.Either way, if the password is successfully
verified,we create a session, issue the cookie, and redirect the user to
the requested page.
1. We can integrate with the LDAP server - Lightweight Directory Access Portocol or authenticate with the access token rather with the password.
2.We can also manage authentication at the permission level which gives us more flexibility.
3. with the above feature, we can set delegated authentication for particular users rest will use their salesforce credentials for login.
4.If user tries to login through online or API, salesforce checks permission settings and access settings after validating the UserName.
5.if user has enabled the single sign on permission setting then salesforce doesn't validates the login credentials.Rather it makes an web service call to org for validating the login credentials.
6. When above permission setting is enabled then salesforce no longer manages the password policies
ex : Password must be required minimum length.
7.Then delegated authentication comes into action, the endpoint service enforces the policies for password.
Note :
The webService validates username,password and Source IP
Source IP : The IP address that originated the login request.
security Modes :
================
1.Simple Passwords (User salesforce login page)
2.Tokens ( Private login page on your company webserver that may be behind your corporate firewall)
3.Mixed (use mobile and client apps)
OpenID Connect :
====================
OpenID Connect is a modern Identity Protocol that leverages OAUTH.
It provides an ID token and UserInfo endpoint.
you can use it for single sign-on (SSO).
Salesforce can act as an OpenID Connect client.
ex: Sign in with Google.
Salesforce can act as an OpenID connect Provider.
Example Login with Salesforce.
OpenID Connect - for social Sign-on into the org.
Login to salesforce org with Google+.
Steps for social sign-on with Google+ into Enterprise Org.
1. Setup MyDomain in the org.
2.Configure an OpenID Connect type Authentication provider pointing to Google.
3.Set a google plus user ID field on user record - for account linking.
4.Update a user record with a valid google plus userID.
5.Configure enterprise branding page to enable Login with Google.
6.Test Login with Google into the enterprise org.
OpenID Connect - For salesforce login into the community.
Login to community with any Salesforce org.
Steps for Single Sign On into Community with any Salesforce Org.
1. Setup OpenID Connect Auth Provider pointing to a Connected App in IDP.
2.Registration Handler code can do user checks based on Email or FederationID.
3.Set the Community Login Page to use this Auth Provider.
Authorization Request
https://ogin.salesforce.com/services/oauth2/authorize
Authorization Response
https://www.example.com/oauth/callback/?
Token Request
Token Response
access_token
id_token
Note :
Client uses ID token to authenticate the end user.
The ID token is represented as a JSON Web Token (JWT).The JWT is singed using a JSON web signature and consist of three parts separated by "."
An ID token has the following syntax :
Base64(JOSE header).Base64(Payload).Base64(Signature)
Every Client must validate the ID-token it receives.It must validate the iss, aud and exp claims. The rest are optional if presented.
what OpenID connect adds?
1.ID token
2.UserInfo endpoint for getting more user information
3.Standard set of scopes
4.Standardized implementation.
OAuth and OpenID Connect :
======================
Use OpenID Connect for (Authentication):
1.Logging the user in
2.Making your accounts avaialble in other systems
Use OAuth 2.0 for (Authorization) :
1.Granting access to your API
2.Getting access to user data in other systems.
Connected App :
=============
Consumer key is essentially the API key associated with
the application (Twitter, Facebook, etc.). This key
(or 'client ID', as Facebook calls it) is what
identifies the client. By the way, a client is a
website/service that is trying to access an end-user's
resources.
Consumer secret is the client password that is used to
authenticate with the authentication server, which is a
Twitter/Facebook/etc. server that authenticates the
client.
Access token is what is issued to the client once the client successfully authenticates itself (using the consumer key & secret). This access token defines the privileges of the client (what data the client can and cannot access). Now every time the client wants to access the end-user's data, the access token secret is sent with the access token as a password (similar to the consumer secret)
