Fig-17: Flow at front channel
Trivial situation is when the payload application consists entirely of a web gui or web site, without any web services call. Never-the-less, this is a very important flow because it is the most common way for Users to interact with the system. It is also a necessary precondition for the web services flows to be initiated and bootstrapped with the necessary tokens, including the IM access token.
Fig-17: Flow at front channel
Example: In our concrete example U authenticates and makes a service
request to A which invokes another service provider B which also
contains information about user U.
Assumptions:
IdP has a table that lists the user name and the password of the user.
IdP passes the permanent userID with a given Service Provider to that Service Provider every time the user logs in to the IdP from the Service
Provider. The identifier is conveyed in a token, e.g.
The Steps of the Protocol with one layer of Service Provider Invocations
User U wants to access service provider A and starts interaction with A.
U is redirected to IdP1 (n.b. IdP discovery is not addressed in this flow, though industry standards like [SAML2core] and [CardSpace] do address it)
U logs in at IdP1. The authentication method is out-of-scope for this flow.
IdP1 returns two encrypted tokens to A:
the token contains U s permanent pseudonymous userID 123A4. It is encrypted such that only A can read it and authenticate the user.
the token is encrypted for the IM and contains the permanent pseudonymous userID of U with IM which is 789IM. The token is bound to A (contains an indication that only A can use it towards IM).
A authenticates U with TokenAuthn (possibly Single Sign-On - SSO). If it is a stand alone service, A returns the results of the services to U and A is done.