Fig-23: Linking Service: Registration phase.
This section addresses Req. D1.2-7.15-PushCred.
Fig-23: Linking Service: Registration phase.
Fig-24: Linking Service: Login with attribute push phase.
The Linking Service model is described more fully in [TAS3D71IdMAnAz]. We just give a brief summary of the model here.
The Linking Service model is based on the following assumptions/requirements:
users typically have multiple attributes (authorisation credentials) assigned by multiple authorities and they are known by different identifiers at each authority
some service providers will require many of these credentials in order to grant access
the user does not want the inconvenience of having to authenticate (login) to each of the attribute authority in order to obtain credentials to give to the service provider
the service provider does want strong cryptographic evidence that each of the authorisation credentials does belong to the user who has initiated the session
the user should be able to set up his policy for which attributes are aggregated by which SPs
the user should be able to provide consent each time his attributes are aggregated by an SP.
The Linking Service is a new component that is under the control of the user, and allows the user to set his link release policy for which of his IdPs may be linked together so that their attributes can be aggregated and sent to the same SP. The user may in addition set an attribute release policy at each of his IdPs that is authoritative for more than one attribute, to say which SP can receive which subset of his attributes from this IdP. Taken together, the link release policy and the set of attribute release policies give the user complete control over which of his attributes can be aggregated together and released to which service providers. The GUI for the link release policy has already been described in Section ?tas3arch-GeneralizedUseCases-UsingLinkingService?. The GUI for the attribute release policy will be very similar to this, but instead of associating IdPs with SPs, the user will associate attributes with SPs. Note that in many cases attribute release policies will not be needed since most IdPs are typically only authoritative for one attribute.
Once the user has linked his IdPs together and set his link release policy at the Linking Service, the user contacts an SP for a service. The front channel steps are as follows
User contacts SP asking for a Service
SP and/or user interact, allowing IdP choice as usual
User is redirected to chosen IdP and Authentication with the IdP takes place as usual
In addition the User can tick a box giving consent for attribute aggregation to take place in this session (see Fig-25)
User is redirected back to SP and is granted access to the service.
Fig-25: The enhanced login screen for attribute aggregation.
The back channel communications that take place between steps 4 and 5 above are as follows:
The IdP sends an authentication SSO statement to the SP, containing a random identifier for the user. This prevents the SP from correlating the user's requests in different sessions. (Note that if the user wishes to be correlated he can arrange for the linking service to send a unique identifier attribute from one of his attribute authorities during the attribute aggregation process, for example, a National Health Number from the Health Authority if the SP is a medical application, or a unique ID from the authenticating IdP). The IdP also sends an attribute statement containing the user's attributes at this IdP, and an attribute statement containing referral(s) to the user's linking service(s). Each referral contains the unique ID of the user as known by the Linking Service and it is encrypted to the public key of the Linking Service.
The SP acts on the referral(s) and contacts the LS's discovery service asking it to return the linked IdPs' discovery services, along with a Boolean saying "I will do it or You do it for me".
The LS decrypts the unique ID of the user, looks this up in its database and finds all the user's linked accounts. If the SP has asked to perform aggregation itself, the linking service returns a Response containing referrals to the discovery services of the user's linked IdPs.
The SP now sends a query message to each of the IdP's discovery services, requesting the contact details of the user's attribute authority. Alternatively, if the linking service is performing the aggregation on behalf of the SP, it sends the same message to each IdP.
The IdP's discovery service locates the user's local account by decrypting the user's unique ID in the referral, and maps the random identifier from the authentication assertion into the user's local account id. The IdP returns a Response containing the contact details of the attribute authority where the random identifier is now valid
The SP or linking service sends an Attribute Query message to the attribute authority, using the random identifier, whereupon the attribute authority returns a digitally signed attribute assertion encrypted so that only the SP can read it.
If the linking service is doing the aggregation, it collects together all the encrypted responses from all the IdPs and then forwards the complete package to the SP.
The SP now has the following digitally signed assertions:
An authentication assertion from a trusted IdP saying that the user has been authenticated, and is to be known by this random id for this session
A set of attribute assertions from trusted attribute authorities saying that the user known by this random id possesses this set of attributes
Based on the above the SP can authorize the user to access the requested resources, sure in the knowledge that trusted authorities have both authenticated the user and assigned attributes to her.