Adding Distributed Trust Management to Shibboleth

1. Adding Distributed Trust Management to Shibboleth Srinivasan Iyer Sai Chaitanya

2. Synopsis • Paper analyses the simplicity of the trust model adopted by the Shibboleth. • Describes an enhanced distributed trust model. • Authorization decision making capability that can be implemented by using X.509 attribute certificates and a Privilege Management Infrastructure such as PERMIS.

3. Shibboleth Overview • Shibboleth is a distributed web resource access control system that allows federations to co-operate together to share web based resources. • Defines a protocol for carrying authentication information and user attributes from a home to a resource site. • The resource site can then use the attributes to make access control decisions about the user.

4. Attributes Temporary Signed-URLs Authentication data Attributes? Target Signed-URL Shibboleth model Home Authentication Server Attr. Auth Web browser

5. Overview Continues • This web based Middleware layer uses SAML ( security assertion Markup Language) • SAML provides the XML standard for exchanging authentication and authorization data between security domains. • SAML provides security between the identity provider and service provider.

6. Shibboleth Sign on and Access Control Stages • In stage one the resource site redirects the user to their home site, and obtains a handle for the user that is authenticated by the home site • In stage two, the resource site returns the handle to the attribute authority of the home site and is returned a set of attributes of the user, upon which to make an access control decision.

7. Complications in Single Sign on • How does the resource site knows the Home site of the user? • How does it trust the handle returned?

8. Answer for Authenticating sign on • Answer is, it is handled by the system trust model. • When resource site asks for home site from the user. He selects it from the list of trusted sites which are already authenticated by Certificates. • Handles are validated by the SAML signature along with the message.

9. Authentication Procedure • User selects the home site from the list. • Home site authenticates the user if he is already registered. • After Home server authentication. It returns a message with SAML sign to the Target Resource site. • Resource site if Sign matches provides a pseudonym (handle) for the user. • Sends an assertion message to Home page to find out if the necessary attributes are available with the user

10. Mechanism to ensure user privacy • Each time provides different pseudonym for the user’s identity. • It needs the release attribute policy from the user attributes each time to provide control over the authority attributes in the target site. • Agreement attribute release policy is between the user and the administrator

11. Trust Model in Shibboleth • Trust is the heart of Shibboleth. • It completely trusts the Target Resource site and Origin Home Site registered in the federation. • Disadvantage of the existing Trust Model is there is no differentiation between authentication authorities and attribute authorities. • There is a scope of allowing more sophisticated distribution of trust, such as static or dynamic delegation of authority.

12. Trust Model in Shibboleth • Another Disadvantage in the existing trust model is it provides only basic access control capabilities. • It lacks the Flexibility and Sophistication that many applications need like to provide access control decisions based on role hierarchies or various constraints such as the time of day or separation of duties.

13. Enhanced Trust Model for Shibboleth • In the basic Shibboleth, target site trusts the origin site to authenticate its users and manage their attributes correctly while the original site trusts the target site to provide services to its users. • Trust is conveyed using digitally signed SAML messages using target and origin server key pairs.

14. Enhanced Trust Model for Shibboleth • Each site has only one key pair per Shibboleth system. Thus there is only a single point of trust per Shibboleth system. • Thus there is a need for a finer grained distributed trust model and being able to use multiple origin authorities to issue and sign the authentication and attribute assertions.

15. Features of Enhanced Trust Model • Multiple authorities should be able to issue attributes to users and the target site should be able to verify issuer/user bindings. • The target should be able to state, in its policy, which of the attribute authorities it trusts to issue which attributes to which groups of users. • The target site should be able to decide independently of the issuing site which attributes and authorities to trust when making its access control decisions.

16. Features of Enhanced Trust Model • Not all attribute issuing authorities need be part of the origin site. A target site should be able to allow a user to gain access to its resources if it has attributes issued by multiple authorities. • The trust infrastructure should support dynamic delegation of authority, so that a holder of a privilege attribute may delegate (a subset of) this to another person without having to reconfigure anything in the system.

17. Features of Enhanced Trust Model(contd) • The target site should be able to decide if it really does trust the origin’s attribute repository, and if not, be able to demand a stronger proof of attribute entitlement than that conferred by a SAML signature from the sending Web server.

18. Trust Models of Shibboleth sites • We can look at trust from two different aspects – • Distribution of trust in attribute issuing authorities. • Trustworthiness of an origin site’s attribute repository.

19. Distribution of Trust • In the simple case the origin site has single attribute issuing authority. • Original site may decide to distribute management of attributes between different trusted authorities

20. Origin site’s Attribute Repository • Target site may or may not trust origin sites attribute repository. • When target site doesn’t trust the attribute repository, then digitally signed attributes are stored instead of storing plain attributes.

21. Trust Models in Shibboleth • Target trusts origin’s attribute repository and origin as a single authority. • This is the original Shibboleth trust model. • Origin will store plain attributes in repository and pass them in digitally signed SAML messages.

22. Trust Models in Shibboleth (cont) 2. Multiple attribute authorities and source trusts all attribute authorities. • Here origin distributes management between multiple authorities and therefore must store attribute certificates in its repository. • Target site uses role assignment sub-policy (RAP) to describe whom it trusts to assign which attributes. • Target site uses TAP to determine which attributes are needed in order to access which targets.

23. Trust Models in Shibboleth (cont) • The target may trust only a subset of the actual attribute authorities at the origin site. • The target may allow dynamic delegation of authority at the origin site, by specifying this in the RAP. • Shibboleth fetches attribute certificates from the origin site rather than plain attributes. • Origins attribute repository may or may not be trusted, however this doesn’t matter since digitally signed AC’s are stored.

24. Trust Models in Shibboleth (cont) 3. Target trusts different attribute authorities at the origin site and elsewhere • Here the target site authorizes users based on attributes assigned to them by different AA’s that are not always co-located with the origin site. • Here AA’s do not push AC’s target sites. The target sites operate in pull mode AC that it needs from AA’s • Once AC’s are retrieved the target will use RAP to determine which AC’s are trusted and TAP to determine if site has necessary attributes to access the resource.

25. Trust Models in Shibboleth (cont) 4. Target and/or origin do not trust origin’s attribute repository but target trusts origin as a single AA

26. Trust Models in Shibboleth (cont) • Here origin stores digitally signed attributes instead of plain attributes. • Format could be X.509 AC’s or SAML attribute assertions. • All attributes should be signed by a organizational attribute authority that is trusted by the target. • When AC’s are handed to the target RAP will check whether they have be signed by the right authority. • TAP is then used to determine if the user has sufficient attributes to be granted access to the target.

27. Trust Models in Shibboleth (cont) 5. Origin distributes trust to multiple authorities, but target doesn’t recognize them

28. Trust Models in Shibboleth (cont) • Here target runs standard Shibboleth but origin wishes to distribute management of attributes to different AA’s. • Origins stores AC’s in its repositories signed by multiple AA’s • However since target runs standard Shibboleth these AC’s cant be passed to the target

29. Trust Models in Shibboleth • Hence origin should run RAP to validate that the AC’s are issued in accordance to its own policy. • This will validate the stored AC’s, extract the attributes that are trusted and pass them to the target.

30. Implementation of Enhanced Trust Model using X.509 PMI • X..509 is a Certificate authority comprises attribute assignments. • the name of the holder of the attributes • the name of the issuing authority • the set of attributes • and the time that they are valid • Optional field to mention if the user can dynamically delegate this attributes to another user

31. X.509 Certificate Authorities (AC) • AC signed by the attribute authority. • provides integrity control and tamper resistance. • Multiple attribute authorities can co-exist, either in a hierarchical relationship or as separate independent authorities. • AC is Stored in target’s PDP (Policy Decision point) to retrieve during authenticating attributes.

32. Authorization by CA using PERMIS • The PERMIS (PrivilEge and Role Management Infrastructure Standards Validation ) X.509 PMI is part of the US NSF Middleware Initiative software release. • PERMIS provides a policy controlled role based access control (RBAC) infrastructure. • user’s roles are stored in X.509 ACs

33. Authorization • ACs are passed along with PDP and PERMIS provides access or denies based on the policy in force at that time. • PERMIS policy is in XML provides dynamic Delegation supports unlike XACML. • XML policy is stored in X.509 attribute signed by Trusted authority of target site.

34. PERMIS Policy • PERMIS PDP is initialized. • Gets the trusted authority and Policy ID matches policy from target entry, checks their signatures, and keeps the one with the correct ID. • Based on the policy make access control decisions. • PERMIS thus forms a good basis for demonstrating the distributed management of trust with Shibboleth.

35. PERMIS RAP • PERMIS contains Role Allocation Sub Policy (RAP) which has • a list of trusted attribute authorities. • the set of attributes they are trusted to assign. • and the groups of users they can be assigned to. • RAP determines the trusted CA which is stored for later use

36. PERMIS TAP • Target Access sub Policy provides the set of targets that are protected by the policy. • TAP controls the current roles/attributes is allowed to access a particular target resource based on content and condition (Environment condition of the system). • PERMIS on the whole helps in supporting multiple authorities and their dynamic role delegation based on distributed target Attribute policies.

37. User Privacy Issues • ACs bind Holders name to the Certificate and if it is the real name of the user privacy is lost. • X.509 Allows Different solutions for the same. • Binding Distinguished Names Which need not be real name, but needs to have meaning to issuing site. Eg( CN = Programmer, CN= 1234, U = University)

38. Privacy Issues • Second issue is the user can be identified by the public key certificate signature linked with X.509 AC • If the user is PKI (Public Key Infrastructure) Enabled which provides a secure Public key pair and a digital signature then the user contents in the signature can be protected

39. Privacy Issue • The Holder can be identified based on the hash of the public key (which can be resolved by generating Random Hash functions each time). • In all the above there is a trade of between “Degree of anonymity” and “Quality of Issuance”

40. Revocations and Performance Issues in SAML versus AC • Short lived SAML assertions need not be revoked. • ACs with long life time has to be revoked once the life time has ended and it is removed from the target PDP. So the target does not have the overhead of scheduling the revocations • In SAML each message has life time and so more overhead to maintain digital signature for each message.

41. Revocations and Performance Issues in SAML versus AC • Incase if the ACs are not stored in the target PDP then it has to invoke ACRL (Attribute certificate Revocations list) to revoke the AC. In this case it becomes more overhead. • In SAML distributed Trust management is not possible whereas AC X.509 provides it.

42. Conclusion • In this paper thus Finer grained Distributed Trust with flexible Decision Making capabilities was described. • How Target and Origin Sites can have Distributed Trusted Model using X.509 PMI? • How it is advantageous over SAML Centralized Trust model?

43. References • http://middleware.internet2.edu/pki05/proceedings/chadwick-distributed-shibboleth.pdf • www.terena.nl/activities/tf-aace/workshop/presentations/Distributed_trust_model1.ppt