1. A Heterogeneous Network Access Service based on PERMIS and SAML Gabriel López Millán (gabilm@dif.um.es) University of Murcia EuroPKI Workshop 2005

2. 2nd European PKI Workshop 2005 2 Content Introduction Authorization Systems Architectural elements and Policies Design Alternatives Conclusions

3. 2nd European PKI Workshop 2005 3 Introduction Current status: Authorization Systems are more and more complex They span domains of administration Depend on many authentication sources Complex management of permissions and policies On the other hand: Many authorization standards Only used in homogeneous systems A professor from University A is not allowed to use the network of University B where there is an agreement between both domains

4. 2nd European PKI Workshop 2005 4 Introduction This work present a case study where we demostrate how two different authorization mechanisms (PERMIS and SAML) can be integrated Using the network access control (NAS-SAML) as scenario application Based on the existing proposals like the Credential Conversion Service (CCS) Interdomain environment from different autonomous domains Integration of different authorization environments

5. 2nd European PKI Workshop 2005 5 Introduction Objetive: A PERMIS user wants to make use of a NAS-SAML domain He has to demostrate he has gained the required ACs Provided by the PERMIS domain This ACs must be translated to into SAML credentials before processing the network request Needed: New entities in home and target domains Definition of how and where ACs will be disclosed and translated Definition of design alternatives

6. 2nd European PKI Workshop 2005 6 Content Introduction Authorization Systems Architectural elements and Policies Design Alternatives Conclusions

7. 2nd European PKI Workshop 2005 7 Authorization Systems: NAS-SAML SAML-based network access service Based on: X.509 identity certificates SAML authorization attributes XACML authorization policies Network Access based on 802.1X and AAA It works both in single and inter-domain scenarios It defines both Pull and Push based communications

8. 2nd European PKI Workshop 2005 8 Authorization Systems: NAS-SAML Quick overview: The user’s home domain defines the set of attributes he plays End user requests network connection in a particular domain (home or foreign) using 802.1X The AAA server obtains the request and requests an Authority to obtain the user’s attributes The AAA server sends an authorization query to a Policy Decision Point (PDP) The PDP grants or denies the access depending on a Resource Access Policy (optinally, oblitations such us security options, QoS, etc. can be returned)

9. 2nd European PKI Workshop 2005 9 Authorization Systems: PERMIS Trust management system based on Attribute Certificates It defines a hierarchical RBAC policy language in terms of roles and permissions specified in the ACs Who is to be granted what type of action on which targets, and under what conditions. It defines a privilege verification subsystem responsibles for authenticating and authorizating the remote user: Access Control Enforcement Function (AEF) – application- specific component Access Control Decision Function (ADF) – application- independent component

10. 2nd European PKI Workshop 2005 10 Authorization Systems: PERMIS Policy elements: SubjectPolicy: subject domains RoleHierarchyPolicy: roles and hierarchical relationships SOAPolicy: trusted SOAs to allocate roles TargetPolicy: target domains covered by this policy (LDAP subtree or URIs) ActionPolicy: Methods or actions supported by the targets TargetAccessPolicy: which roles have permissions to perform which actions on which targets, under which conditions.

11. 2nd European PKI Workshop 2005 11 Content Introduction Authorization Systems Architectural elements and Policies Design Alternatives Conclusions

12. 2nd European PKI Workshop 2005 12 Architectural elements and Policies: Credential Conversion Scenario

13. 2nd European PKI Workshop 2005 13 Architectural elements and Policies: Credential Conversion Scenario Defines two new components User Attribute Manager (UAM) Credential Conversion Service (CCS) (described in [CCS]) New components Must respect the already existing components Should be able to interact in the most transparent way Defines the policies used for the disclosure and conversion processes Disclosure policy Conversion policy

14. 2nd European PKI Workshop 2005 14 Architectural elements and Policies: New Components User Attribute Manager (UAM) The user’s home domain needs a module able to: receive credential requests from an external domain decide which of the user’s attributes must be revealed Where are you from? problem We assumes fixed UAM locations or discovery via an information service query to a trusted source It is able to: understand queries and create authorization responses in SAML returns to the NAS-SAML domain only those attributes specified by the Disclosure policy

15. 2nd European PKI Workshop 2005 15 Architectural elements and Policies: New Components User Attribute Manager (UAM) How it works: Pull model: UAM receives attribute queries from the target domain (CCS) UAM obtains the user’s attributes and asks the PDP about the visibility of those (Disclosure policy) UAM returns a response message to the CCS including the user’s attributes in source format (ACs) Push model: UAM receives attribute queries from the end user UAM obtain in the same way the disclosed attributes (ACs) UAM sends a conversion query to the appropiate CCS UAM returns to the end user the converted credentials in target format (SAML)

16. 2nd European PKI Workshop 2005 16 Architectural elements and Policies: New Components Credential Conversion Service (CCS) We don’t want the non-SAML domain issues SAML assertions The NAS-SAML domain needs a component responsible for: recovering from an external domain the user’s attributes (in source format, i.e. X.509 ACs) translating them into internal credentials (in target format, i.e. SAML statements) CCS: defines different architectural elements extends standard SAML elements is located in the NAS-SAML domain receives attribute conversion queries related to a foreign user

17. 2nd European PKI Workshop 2005 17 Architectural elements and Policies: New Components Credential Conversion Service (CCS) How it works: Pull model: The AAA server asks the CCS about the user’s attributes CCS discovers the user’s home domain and forwards the query to the UAM CCS obtains the source user’s credentials (ACs) and translate those to SAML statements (Conversion policy) CCS returns these statements to the AAA server Push model: CCS receives conversion query from the user’s home domain UAM

18. 2nd European PKI Workshop 2005 18 Architectural elements and Policies: Integration Policies Disclosure Policy UAM needs a policy to specify which attributes can be revealed to which target domains We suppose the home domain is based on the PERMIS infrastructure Disclosure Policy: identifies the external CCSs (foreign domains) assigns specific roles to every domain based on the existing relationships defines the set of attributes that can be revealed and under which conditions uses the resource access control policy defined by PERMIS

19. 2nd European PKI Workshop 2005 19 Architectural elements and Policies: Integration Policies Disclosure Policy elements: Subjects: external domains allowed to request user’s attributes Roles: set of roles played by the external domains SOA: Authorization Authority managing the ACs Targets: set of users whose attributes are to be disclosed Actions: only disclose action has been defined, the attribute to be disclosed is used as parameter TargetAccess: which attributes assigned to a particular set of users can be disclosed to which domains, under which conditions.

20. 2nd European PKI Workshop 2005 20 Architectural elements and Policies: Integration Policies – Disclosure

21. 2nd European PKI Workshop 2005 21 Architectural elements and Policies: Integration Policies Conversion Policy CCS needs a policy describing how attributes from the user’s home domain must be mapped into internal attributes It is based on XACML Policy elements: Subject: One or more subjects specifying the related home domains Resource: represents the credentials issued by the home domain that need to be translated into internal credentials Action: only translate action has been defined Obligation: specifies how to translate the credentials

22. 2nd European PKI Workshop 2005 22 Architectural elements and Policies: Integration Policies - Conversion

23. 2nd European PKI Workshop 2005 23 Content Introduction Authorization Systems Architectural elements and Policies Design Alternatives Conclusions

24. 2nd European PKI Workshop 2005 24 Design Alternatives Interacctions between components depend on the requirements imposed by the user to gain access to the network Pull model: authorization tasks are performed by the system Minimum overload, suitable for limited terminals Push model: involves support for selecting and transporting attributes from the end user More intrusive approach Independently of the selected approach, end user requesting network access should be authenticated before starting the authorization process We suppose public key certificates authentication Authentication is delegated, for example, using a cross-certification relationship between the involved domains

25. 2nd European PKI Workshop 2005 25 Design Alternatives: Alternative 1 Pull model Provides an authenticated and authorized connection in a transparent way Avoids the client software to be modified to support this scheme It does not provide to the user control about the required type or service User can not select the set of attributes to be presented Most of the times it is not a disadvantage

26. 2nd European PKI Workshop 2005 26 Design Alternatives: Alternative 1 Pull model

27. 2nd European PKI Workshop 2005 27 Design Alternatives: Alternative 2 Push model based on SAML Attributes Users are able to present their authorization credentials during the network access request Credentials are expressed using SAML attribute statements containing the roles he plays How it works: First: User requests his attributes from his home domain He specifies the desired target domain and resource The user obtains the converted attributes Second: User presents those converted attributes to the target domain It provides to the end user complete visibility and control of the authorization process In the other hand, user software has to be modified in order to deal with SAML statements

28. 2nd European PKI Workshop 2005 28 Design Alternatives: Alternative 2 Push model based on SAML Attributes

29. 2nd European PKI Workshop 2005 29 Design Alternatives: Alternative 3 Push model based on Attribute Certs. End user presents to the AAA server are the user’s Attribute Certificates, obtained from the UAM ACs contains the roles the user plays How it works: First: User requests his ACs from his home domain He specifies the desired target domain and resource Second: The user presents the selected ones to the AAA server in the target domain This step involves the authentication, the credentials conversion and the authorization decision process

30. 2nd European PKI Workshop 2005 30 Design Alternatives: Alternative 3 Push model based on Attribute Certs.

31. 2nd European PKI Workshop 2005 31 Content Introduction Authorization Systems Architectural elements and Policies Design Alternatives Conclusions

32. 2nd European PKI Workshop 2005 32 Conclusions We propose a solution to integrate two different authorization schemes It is provided an example of authorization mechanism that can be integrated: PERMIS and SAML NAS-SAML is used as the application scenario Beside new components (UAM and CCS), related policies are presented (Disclose and Conversion policies) Policies based on PERMIS XML authorization policy and XACML No aditional authorization technologies are needed We present three different design alternatives, which can be used depending on the user’s requirements This scenario can be easily adapted to the reverse order (using SAML in the home domain, and PERMIS in the target domain)

33. Thanks for your attention Questions? Gabriel López Millán gabilm@dif.um.es