Setup Federated Authentication (SAML) based SSO

SAML stands for “Security Assertion Markup Language” and it is Open standard for exchanging Authentication and Authorization between Systems. SAML based authentication is supported by all editions of Salesforce.
User Validation can be initiated by any one of below two types:
  1. Service Provider Initiated SSO
  2. Identity Provider (IDp) initioated SSO
We are going to use Identity Provider Initiated SSO in this article. Means User will Login from Outside(IDp) and will be redirected to Salesforce (Service Provider). Identity Provider must follow Federated Authentication (SAML) standard which should be deployed to DMZ (URL should be publicly accessible on Internet) layer of your Organization. As a Salesforce developer you should assume that you will always get IDp URL which implements SSO and implements valid SAML response. To Quickly start with this tutorial assume that your organization already deployed SAML based Authentication endpoint and for that we will be using great Heroku app available freely as open source named “AXIOM“.
ID Initiated Single Sign On :
In IDP Initiated SSO, User Directly logins to Identity provider and IDP redirects user to proper Salesforce Instance with SAML assertion in request (Service Provider). If SAML assertion is valid then Salesforce validates that user successfully.
Step 1 : Enable My Domain

Step 2: Download Identity Provider Certificate
In this step we are going to get certificate from IDp. This certificate will be used by Salesforce to validate that client coming for user authentication is valid to avoid any unauthorized access to Service Provider (In our case it is Salesforce).
You can download certificate by navigating to Axiom application here.

Step 3: Enable Single Sign On in Salesforce
Navigate to “Setup | Security Controls | Single Sign-On Settings” and check “SAML Enabled” option.
Step 4 : Configure Single Sign On
Step 4 : Configure Single Sign On
Once SAML is enabled, new section will appear on same page to create New “SAML Single-On Settings”.
Click on New Button and provide following informations
  • NAME – any name will work
  • API Name – any valid name
  • Issuer – Any name. You must remember this as your IDp must pass the same name while sending request
  • Identity Provider Certificate – Upload certificate here downloaded on step 2.
  • Entity Id – “https://saml.salesforce.com”
  • SAML Identity Type – Assertion contains the Federation ID from the User object
  • SAML Identity Location – Identity is in the NameIdentifier element of the Subject statement
  • Identity Provider Login URL – “http://axiomsso.herokuapp.com/RequestSamlResponse.action” (This URL must be publicly accessible on Internet)
  • Service Provider Initiated Request Binding – HTTP POST
Step 5: Generate a SAML Response
Navigate to this URL and click on “generate a SAML Response” link.
Enter following detail in next screen:
  • SAML Version – 2.0
  • Username OR Federated ID – Once saml is enabled, One new field is created on user record “Federation ID”. 
  • User ID Location – Subject
  • Issuer – Issuer name which we already in Step4 while configuring SSO. In our case it is AXIOM
  • Recipient URL – This should be “Salesforce Login URL” which will be visible once we save SSO settings in Step 4. You can see it in Image 2 above.
  • Entity Id – https://saml.salesforce.com
  • SSO Start Page – http://axiomsso.herokuapp.com/RequestSamlResponse.action
  • User Type – Standard
After providing above details click on “Request SAML response” button.

In this page, you can see format of SAML response. You dont have to change anything on this screen, click on Login button.
If everything is OK, you will be on Salesforce Home page.


Comments

Post a Comment

Popular posts from this blog

Apex Trigger Framework in Salesforce with best practise

Image
                                                            Trigger framework is not just needed for having single object per trigger guidance but also helps in different other reasons. According to the trigger framework : 1) Create a single trigger for each object. 2) A handler class which will call Action or Apex Interface based Trigger Framework Implementation One Trigger -One Object Policy Framework Implementation Bulkified Code  Avoid SOQL Queries or DML statements inside FOR Loops  Using Collections, Streamlining Queries, and Efficient For Loops   No  Hardcoding IDs Types of Framework available : 1.Handler/Controller Framework 2.Lightweight Apex Trigger Framework (Source:  http://chrisaldridge.com/triggers/lightweight-apex-trigger-framework/ ) Handler Framewo...
Read more

Apex CPU Limit Error : after running into an Apex CPU limit error whether anything is committed to the database

In a batch that updates an object that then activates a trigger,  would it stop at the object level or at the trigger level or does it depend on  when the apex limit is hit? Any governor limit, including Apex CPU timeouts, reverts all changes to the database for the  entire  transaction. That means no records are created, updated, deleted, undeleted, merged, converted, etc. The  only  exception to this rule is that any logs that are enabled will be preserved (in Setup > Monitoring > Debug Logs).  In the case of a batch, if it occurs in the start method, the entire batch is aborted, while ' if it occurs during an execute function, only that single batch is aborted (but prior batches are already committed, and future batches may still successfully commit), and  in the finish method, a governor limit would prevent chaining calls, sending emails, etc.
Read more

SALES FORCE ORDER OF EXECUTION

Triggers and Order of Execution When a record is saved with an insert, update, or upsert statement, the following events occur in order: 1. The original record is loaded from the database (or initialized for an insert statement) 2. The new record field values are loaded from the request and overwrite the old values 3. All before triggers execute 4. System validation occurs, such as verifying that all required fields have a non-null value, and running any user-defined validation rules 5. The record is saved to the database, but not yet committed 6. All after triggers execute 7. Assignment rules execute 8. Auto-response rules execute 9. Workflow rules execute 10. If there are workflow field updates, the record is updated again 11. If the record was updated with workflow field updates, before and after triggers fire one more time (and only one more time) 12. Escalation rules execute 13. All DML operations are committed to the database 14. Post-commit logic executes, such as sending...
Read more