Apex Code Development You need to sign in to do that
Don't have an account?
garyb Delegated authentication & mobile apps
Hi,
We want to use delegated authentication so that mobile users can access Salesforce mobile apps without entering usernames and passwords. We're looking to use username and passwords (rather than username & token).
When using delegated auth for desktops, you can (for example) provide a link on an intranet page for users that will take the user to a page that passes the user's username and password to salesforce.com in a POST request. That user has a delegated auth enabled profile, so salesforce.com passes the credentials to a delegated authentication authority.
That part I'm clear on!
What I want to know is - how does this work for mobile application users? If a user downloads Salesforce.com Mobile they need to identify to the application what their username and password is. But if a user is SSO enabled, this will mean nothing to them.
So how does a user identify who they are? Is this method reliant on users entering their email address as their username (and therefore it is implicit that their username will be the same as their email address) and their network password as their salesforce.com password? Or does the mobile need to be routed through a proxy that will pick up the attempt to visit the login page and construct the necessary POST request instead?
Any input appreciated, especially from anyone with experience of doing this!
Still confused by your rephrasing...so instead, let my try and quickly explain how these work.
Delegated Authentication is used when we collect a user's username and a credential. Notice I didn't say password. Password is an option, but we don't really care what the credential is....the main point is that we've collected it via our login page, or one of our login APIs. When these interfaces are used, we look at the username, check to see if delegated authentication is enabled, and if so we callback to the customer to validate the credential. If it's not enabled, we treat it as a password and check against out database. The result is that you can pass all sorts of credentials over delegated auth ( passwords, one time passwords, 2 factor codes, cryptographic tokens, saml assertions...whatever ) Using this, you can build a single sign-on solution by posting tokens to us, or do something as simple as simply using your corporate password on our login page. In fact, if your delegated auth endpoint is quite intelligent you can use more than one of these techniques at the same time.
When using SAML, the customer is responsible for authenticating the user. We simply redirect users to the customers Identity Provider. The IDP logs the user in and sends them back to us with a SAML assertion. We process the assertion and generage a session. SAML is enabled at an org level and is generally optional ( although there are techniques to force it to be mandatory ) It can be used with delegated authentication or regular username/password login if you wish. It's not really a matter of one permission winning over the other...It simply matters how the user shows up to the product.
So - to explain how this works with Mobile/Desktop apps
1) All login to salesforce, including mobile and desktop apps can always use a username/password against our database, or validated using Delegated Auth
2) All login to salesforce, including mobile and desktop apps can always use a username, and some token that the user can enter by hand ( one time passwords and such ) using delegated auth
3) We are now rolling out clients that can support Single Sign-On via SAML ( or with some minor work SSO protocols written with Delegated Auth ) All the Chatter clients are able to do this, and we're working on others.
All Answers
Hey garyb - few things here
1) Can you clarify this, as it seems to contradict itself:
"We want to use delegated authentication so that mobile users can access Salesforce mobile apps without entering usernames and passwords. We're looking to use username and passwords (rather than username & token)."
2) When using Delegated Auth, if you're not using a token based approach, then generally the customer just comes to our login page and fills in their username and password. No need to start on your intranet if you're not using tokens
3) Delegated Authentication always uses the Salesforce Username in order to determine who the user is and how to process their credentials. If the user is setup to use delegated authentication, we'll simply call back to you to validate their credential
Hi Chuck, thanks for getting back to me. I think I've been reading too much about SSO and confused a few points between the different types, so I'll expand below.
First point - yes, what I said was totally confusing :) What I meant to say was that we don't want users entering a username and password, and that the version of delegated authentication we're looking to use is sending username & password (as opposed to username & a token). I guess there's an implicit "on behalf of the user" my brain was adding in that I should've put in my post, apologies about that.
As I said, I think I may have gotten myself confused, so I'll rephrase the question as to my current understanding. Using delegated auth (on a desktop, ignoring mobile for now), a user can enter a username and password, and this will be passed to the delegated authentication authority (DAA). Therefore, a user could enter their username and password for their corporate network, and the DAA could then check that against e.g. the corporate LDAP. This would grant access to salesforce.
So far so good? Now for the important part:
Does this work in the same way for the mobile applications, particularly Salesforce Mobile and Chatter Mobile? A user can enter their corporate network username & password, and get access as above. Subsequent logins from the mobile app are with the token from that first authenticated login. Chatter Mobile looks like it's opening up a regular login page, but it's not so clear what Salesforce Mobile is doing (on the iPhone at least) - I take it this will work as described?
Whilst I'm posting - is it possible to grant a user both federated and delegated SSO? If a user who has federated access is assigned a profile that uses delegated auth - which permission wins? (My money's on delegated...)
Thanks again for getting back to me, and sorry for pestering :)
Still confused by your rephrasing...so instead, let my try and quickly explain how these work.
Delegated Authentication is used when we collect a user's username and a credential. Notice I didn't say password. Password is an option, but we don't really care what the credential is....the main point is that we've collected it via our login page, or one of our login APIs. When these interfaces are used, we look at the username, check to see if delegated authentication is enabled, and if so we callback to the customer to validate the credential. If it's not enabled, we treat it as a password and check against out database. The result is that you can pass all sorts of credentials over delegated auth ( passwords, one time passwords, 2 factor codes, cryptographic tokens, saml assertions...whatever ) Using this, you can build a single sign-on solution by posting tokens to us, or do something as simple as simply using your corporate password on our login page. In fact, if your delegated auth endpoint is quite intelligent you can use more than one of these techniques at the same time.
When using SAML, the customer is responsible for authenticating the user. We simply redirect users to the customers Identity Provider. The IDP logs the user in and sends them back to us with a SAML assertion. We process the assertion and generage a session. SAML is enabled at an org level and is generally optional ( although there are techniques to force it to be mandatory ) It can be used with delegated authentication or regular username/password login if you wish. It's not really a matter of one permission winning over the other...It simply matters how the user shows up to the product.
So - to explain how this works with Mobile/Desktop apps
1) All login to salesforce, including mobile and desktop apps can always use a username/password against our database, or validated using Delegated Auth
2) All login to salesforce, including mobile and desktop apps can always use a username, and some token that the user can enter by hand ( one time passwords and such ) using delegated auth
3) We are now rolling out clients that can support Single Sign-On via SAML ( or with some minor work SSO protocols written with Delegated Auth ) All the Chatter clients are able to do this, and we're working on others.
Chuck, thanks for your help with this, my understanding is much clearer now. Basically I'd confused myself with what we were trying to do and lost sight of what delegated auth could/should be used for...
My original post was saying that rather than passing a token as the credential, we'd be passing a password. This is partly where I got confused - by "passing" I meant "passing on behalf of the user", for example, by hitting an intranet page that can put the user's credentials into a POST request for the user, rather than the user seeing a login screen and typing their username and password in manually.
Don't worry if this is still confusing, I'm clear on what needs doing :) We'll set up DA, users will enter their corporate username/password into mobile apps, our DA web service will authenticate those details, the user will authenticate just the once and get a token, job done.
Thanks again, you've been a massive help!