SalesforceA and SecurID Access
- Subscribe to RSS Feed
- Mark as New
- Mark as Read
- Bookmark
- Subscribe
- Printer Friendly Page
- Report Inappropriate Content
We looked at SFDC apps before here (Salesforce Rich Client setup by Karim Elatov) and here (Salesforce1 app login video by Joseph Macaluso).
Today, I just wanted to give a quick update on this, specifically about SalesforceA.
SalesforceA is the app that SFDC administrators can use to perform various administrative tasks such as unlock user accounts.
In terms of authentication and setup it doesn't really differ that much from the standard Salesforce1 app.
Look at the guide by Karim for the details about setting up SFDC as a SAML SP.
Once you did that you can then log into SalesforceA - but keep in mind that this only succeeds if the account you use is a SFDC admin.
Here are some screenshots:
When you start the app the first time you are asked (unsurprisingly I might add) to log in:
Click on the "Sign In" button.
You'll be presented with something that looks a lot like the SFDC login screen in your web browser. That's because what you see is a web page rendered in a browser object inside the SalesforceA app.
Now you have to click on the "Use Custom Domain" link on the lower right corner.
You'll be asked for your custom domain.
Next you'll be presented with the login screen of the target domain OR you might be automatically redirected to the IDP (SecurID Access). This really depends on the setup at SFDC. In my case the SFDC instance I use actually has multiple IDPs it trusts. So I have to select the one I want:
After I did that I'm redirected to my SecurID Access login page and fill out the username and password fields.
Again: this has to be for a user that has administrative rights inside SFDC - otherwise SalesforceA won't like it.
After the login completes (and maybe after a step-up if the policy requires it) the SalesforceA app will present this screen to approve access by the user to the SFDC instance.
Some technical background: SFDC consumed the SAML assertion from SecurID Access and now exchanges that session information for a OAuth token - as soon as "Allow" is selected.
....and we are in!
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.