I was recently asked by a customer “What configuration changes, if any, need to be made for the resource providers to accept both the old local database authentication, and the new federated SAML or OpenID
Connect authentication?”
Remember, a person may navigate to an RP directly, or have an RP bookmarked. You can’t count on the person navigating via the gateway portal.
At a high level, the RP will need to update their application to support more than one workflow for authentication. This involves establishing a procedure for “Discovery” to bootstrap identifying a person who is
currently an anonymous Internet request. The discovery process will determine whether to prompt the person for their existing username and password, or to re-direct the person’s browser to a trusted IDP for
authentication.
How the RP handles discovery, is up to them. Here are a few examples of how different websites accomplish this:
1) Guide the person to select the appropriate IDP. A good example of this is the Educause Login Page
2) Use DNS hostnames to provide the discovery “hint” to the websites. A good example of this is salesforce.com
They issue each partner IDP a dns sub-domain, for example “gluu.salesforce.com”
When their web servers sees the inbound hostname, it can select the appropriate IDP and protocol for authentication.
3) Prompt the person to enter either an identifier or some kind of hint, for example an email address or an organization’s name. The app can then set a permanent cookie to record the person’s discovery
selection and automatically route subsequent requests
4) OpenID Connect Discovery
Ask the Person for an email address, use the specified hostname to send an HTTP GET Request ala Webfinger, now OpenID Connect Disovery:
GET /.well-known/openid-configuration HTTP/1.1
Host: seed.gluu.org
You can see a sample Response from Gluu’s test OpenID server:
http://seed.gluu.org/.well-known/openid-configuration
This response tells the RP where to register to get an API key and secret (where meaning what URL), where to re-direct a person to be authenticated, and where is the USER_INFO endpoint, where the RP can
request user claims (i.e. email address, phone number, first name, etc.).
5) SAML Discovery
For more info, see the DiscoJuice open source product.
Enrollment
Questions about enrollment are common. Consider the workflow for enrollment post-authentication. What is the best way to reconcile existing accounts with your federated accounts?
Do you allow users to use their existing usernames and passwords?
Do you force users to create a new username and password in a registration process?
How you we reconcile these accounts with existing accounts at resource providers? Some users may already have work on a resource provider they wantto be able to access.
Each app needs to be considered on a case-by-case basis. Each RP with legacy local database accounts needs to define an enrollment process for new people who show up via federated identity, and for
existing users who are upgrading to federated identity. Whether the RP wants the person to create a local username, or to use another user claim (like the email address) to identify the person, is up to them.
Post-enrollment, the RP should not accept the old password. In fact, old passwords should be obliterated, and of course no new passwords should be collected. The RP may want to check if a person’s
information is updated at the backend IDP. On eachauthentication, the RP can request the latest user claims (i.e. email address, phone number, etc.) and update its local database if necessary.
The Gluu Server Blog 