1. Shib-Grid Integrated Authorization (Shintau) George Inman (University of Kent) TF-EMC2 Meeting Prague, 5 th September 2007

2. Contents Introduction User Requirements Conceptual Models Proposed Protocol Designs Questions and Further Information

3. Introduction Many grid and campus based network applications are now being enabled with attribute based authorisation The set of attributes used for this act of authorisation are generally provided by a single entity known as an Identity Provider Researchers and early adopters are realizing that a single source of user attributes is insufficient for authorization in many applications

4. What is the Shintau Project? The Shintau project has the following goals –To provide an internationally recognised standard for attribute aggregation that … Reflects the needs of its end users Implements existing standards Preserves user privacy –To implement these new standards within a Policy Enforcement Point that will evaluate the collected attributes according to the trust policy of the Service Provider and return the valid set of attributes to the SP's Policy Enforcement Point –To build a pilot demonstrator for the National Grid Service that will show how attributes from multiple AAs can be integrated together and used in authorisation decision making at grid sites that use shibboleth IdPs. –To release all the developed software as open source code through NMI/OMII to the community at large, with a full set of specifications and documentation

5. User Requirements Elicited from a questionnaire based survey distributed via email to members of 12 international mailing lists We received 26 responses from security professionals already working in the general area of network authorisation and virtual organisations After analysis of the responses the following 12 requirements were agreed upon …

6. User Requirements Attribute aggregation must be usable in a variety of ways: Humans via web browsers, Applications via APIs and Grid users via grid clients etc. Privacy protection of user attributes is of high importance and this should be through the use of technical controls, which are independent of legal means. Service Providers should be able to track users between sessions if required

7. User Requirements Service Providers should be able to learn the true identity of users in exceptional circumstances, but only by contacting the user’s IdPs. IdPs should only be able to communicate with each other to link together the attributes of a user with the user’s permission. Service providers should only be able to query multiple IdPs, in order to pull additional attributes for authorisation purposes, with the user’s permission.

8. User Requirements Should be able to tunnel through firewalls using existing open ports (i.e. use http/https). The system should use existing standard protocols and only extend them in a standard way if necessary. The proxying of information should be supported through multiple hops/proxies.

9. User Requirements The ability to sign assertions should be supported for all exchanges. The SP should be able to require that all assertions are signed by their authoritative sources. It should be easy to use by end-users and require the minimum amount of user interaction

10. Conditions required for Attribute Aggregation Before attribute aggregation can take place, the following is assumed to have already taken place: –the user has registered with a number of IdPs, and has been assigned various attributes by each of them. –each SP and IdP has a bilateral trust relationship allowing them to communicate successfully with each other.

11. The Linking Service Our Aggregation models require that a new Linking Service Entity (LS) be defined that … – can store user attributes assuming the following conditions are met It is a trusted third party used to link a user’s identity provider accounts together It has no knowledge of which user attributes each linked IdP holds –can receive and issue referral assertions, attribute requests and attribute responses

12. Referral Assertions A referral assertion is a data construct that represents a user’s account at an IdP Conceptually the Referral assertion should contain … –A user ID that is the PId (persistent identifier) of the user, originally generated by the recipient IdP, and encrypted to the public key of the recipient IdP. –The name of the recipient IdP (or LS) that is the destination of the Referral. –A link to the authentication assertion that was created for this user session. –The name of the SP that requires the user’s attributes –The name of the initiator of the Referral (i.e. the authenticating IdP or LS) –The whole construct is digitally signed by the creator of the Referral (i.e. the authenticating IdP or LS)

13. The Linking Model In order to facilitate the aggregation of attributes there must be some way for the user to indicate that he posses multiple IdP accounts and more importantly that he wishes them to be used for aggregation In our linking Model if a new user wishes to link an IdP account –The user chooses the identity provider he wishes to link to at the linking service via some act of identity provider discovery –The linking service redirects the user to this IdP for authentication –A persistent identifier is returned to the linking service which it uses to create a new account in its database

14. The Linking Model If an existing user wishes to link additional IdPs to his pre-existing account –The user chooses any previously linked IdP for authentication from the LS –The IdP returns a persistent identifier to the LS which is matched against one of the users identity provider entries –The user is asked to authenticate to the IdP that he wishes to link –The new persistent identifier is linked to the user account discovered in the initial act of authentication User AgentLSIdP AIdP B 1.Service Request 2. HTTP Exchange 3. Authentication Request HTTP 302 4. Authentication 5. Authentication Response 6. HTTP Exchange 7. Authentication Request 8. Authentication 9, Authentication Response

15. Trust Requirements During the Linking Protocol All IdPs must trust the LS to hold their PIds securely, and to hold the links between the PIds securely and with integrity. The LS is trusted to not release the linked information for a user (PId-IdP tuples) to anyone without good cause e.g. a legal requirement, or a linked IdP requests this via a Referral. The LS trusts each linked IdP to authenticate the user correctly, and to return a PId that is unique to this user and that will only be used for subsequent interactions about this user.

16. Aggregation Models Two Proposed Solutions –SP Based Aggregation The SP requests account information from the LS and takes responsibility for the act of requesting and retrieving user attributes –Linking Service Based Aggregation The linking service is used to query for attributes directly, the attributes themselves are signed and returned to the SP via the LS which cannot read the attributes

17. Service Provider Based Aggregation The user requests a service from the SP The SP redirects the user to an IdP for authentication as now The IdP performs its normal authentication procedure and returns the usual set of attributes to the SP, but in addition returns a new protocol element termed a Referral The Referral element in this case points to the Linking Service If sufficient attributes are returned or the SP does not trust the LS the referral is ignored If additional attributes are required the SP forwards the referral to the LS

18. Service Provider Based Aggregation The LS receives the Referral from the SP and sees that it is requesting attributes for a registered user of this linking service and extracts information about the linked IdPs from its internal database The LS returns a set of Referrals to the SP The SP forwards the Referrals to each IdP deemed to be trustworthy Each IdP interprets its Referral, locates attributes for the identified user, and returns them to the SP The SP aggregates together all of the returned attributes and makes its authorisation decision based upon them

19. Service Provider Based Aggregation User AgentSPLSIdP AIdP B 1. Service Request 2. Authentication Request HTTP 302 3. Authentication 4. Authentication Response 5. Attribute Query 6. Attribute Response 7. Attribute Query 8. Attribute Response 9. Attribute Query 10. Attribute Response 11. Attribute Response

20. Linking Service Based Aggregation The user requests a service from the SP The SP redirects the user to an IdP for authentication as now The IdP performs its normal authentication procedure and returns the usual set of attributes to the SP, but in addition returns a new protocol element termed a Referral The Referral element in this case points to the Linking Service If sufficient attributes are returned or the SP does not trust the LS the referral is ignored If additional attributes are required the SP forwards the referral to the LS

21. Expected Changes to Existing Technology IdPs and SPs cannot participate in attribute aggregation without changing their software and supporting system configurations. The requirements placed on the IdPs and SPs are as follows –IdPs will need to increase their internal storage to record for each user which LS they are using and the PId to be used with it. –IdPs will need to hold meta-data about each LS they trust –IdPs will need to have software that is capable of: creating outgoing Referrals to LSs after they have authenticated users, and processing incoming Referrals from LSs. –SPs will need to understand Referrals returned from IdPs and LSs, and be capable of forwarding them to their destinations. –SPs will need to be capable of validating digital signatures and decrypting attribute assertions. –IdPs will need to be capable of encrypting attribute assertions and signing them

22. Linking Service Based Aggregation The LS receives the Referral from the SP and sees that it is requesting attributes for a registered user of this linking service and extracts information about the linked IdPs from its internal database The LS contacts the linked IdPs directly The IdPs return the signed attributes to the LS which collates them and returns them to the SP The SP makes its authorisation decision based upon the set of attributes returned from the LS

23. Linking Service Based Aggregation User AgentSPLSIdP AIdP B 1. Service Request 2. Authentication Request HTTP 302 3. Authentication 4. Authentication Response 5. Attribute Query 6. Attribute Response 7. Attribute Query 8. Attribute Response 9. Attribute Query 10. Attribute Response 11. Attribute Response

24. Trust Requirements During Service Invocation The SP must trust the LS to hold the established links securely and with integrity, and to release the correct links when requested to (indirectly) by the user. The LS trusts each linked IdP to authenticate the user correctly, and to only send Referrals to it as a direct result of a user service request that was authenticated by that IdP. All linked IdPs must trust the authenticating IdP to authenticate the user correctly. The SP must trust the authenticating IdP to authenticate the user correctly. The SP must trust each IdP to correctly generate and process Referrals and to only send attributes that pertain to the authenticated user that they are authoritative for.

25. Implications of lack of trust If an SP does not trust an IdP that is the target of a Referral or the sender of a signed attribute assertion, it can simply discard the Referral or attribute assertion If the SP does not trust the authenticating IdP then the user will be denied service. If the SP does not trust the LS, it will simply discard the Referral to the LS and grant the user access based on the attributes obtained from the authenticating IdP. If the LS does not trust the authenticating IdP then no link will be stored to that IdP and no Referrals will ever be sent from the authenticating IdP to the LS. If the LS does not trust the SP then it will return an empty set of Referrals to it and the user will be granted access based on the attributes obtained from the authenticating IdP. If the LS does not trust an IdP then no link will be stored to that IdP and no Referrals will ever be generated to that IdP. If the authenticating IdP does not trust the LS, then it will not return a PId to it at linking time, and no link will be stored by the LS. No Referrals will ever be generated by the authenticating IdP for the LS. If the authenticating IdP does not trust the SP, then it will not authenticate the user or send any attributes to the SP. If the authenticating IdP does not trust one of the other linked IdPs, this does not matter, since the authenticating IdP does not have to rely on the other linked IdP for anything, and cannot be damaged by it. If an IdP does not trust the authenticating IdP then it will not return any attributes to the SP in response to the Referral that accompanies the authentication assertion from that IdP. If an IdP does not trust the SP then it will not return any attributes in response to the Referral containing that SP. If an IdP does not trust the LS then it will not return a PId to it at Linking time, and no link will be stored by the LS. No Referrals will ever be generated by the LS to the IdP.

26. Questions and Additional Information Shintau Website –http://sec.cs.kent.ac.uk/shintau/ Shintau Mailing List –shintau@jiscmail.ac.uk My email address –G.Inman@kent.ac.uk