A Heterogeneous Network Access Service based on PERMIS and SAML Gabriel López Millán...

A Heterogeneous Network Access Service based on PERMIS and SAML

Gabriel López Millán([email protected])University of MurciaEuroPKI Workshop 2005

2nd European PKI Workshop 2005 2

Content Introduction Authorization Systems Architectural elements and Policies Design Alternatives Conclusions


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


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


IntroductionObjetive: 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


Content

Introduction Authorization Systems Architectural elements and Policies Design Alternatives Conclusions


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


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)


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


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.


Architectural elements and Policies:Credential Conversion Scenario

NAS domainPERMIS domain

PDP

AttributeManager

ConversionService

1. network access attempt

2. obtain andconvert credentials

3. give me user’scredentials

PERMIS userrequestingaccess in a

NAS domain

4. select visibleattributes

5. visibleattributes

6. user’s ACs

AAA7. conversionprocess

8. SAML attrs

PDP


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


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



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)



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



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


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



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.


Architectural elements and Policies:Integration Policies – Disclosure

<X.509_PMI_RBAC_Policy OID="2.6.2004.24.1.2005"> <SubjectPolicy> <SubjectDomainSpec ID="SD_International_CCSs">

<Include LDAPDN="cn=CCS, o=SAMLDomain,c=C"/> </SubjectDomainSpec> </SubjectPolicy> <RoleHierarchyPolicy> <RoleSpec Type="permisRole"

OID="1.2.826.0.1.3344810."><SupRole Value="ShortTerm-CCS"></SupRole> <SupRole Value="LongTerm-CCS">

<SubRole Value="ShortTerm-CCS"/></SupRole></RoleSpec>

</RoleHierarchyPolicy> <SOAPolicy> <SOASpec ID="PERMISDomain_UAM"

LDAPDN="cn=UAM,o=PERMISDomain,c=C"/> </SOAPolicy> <RoleAssignmentPolicy> <RoleAssignment>

<SubjectDomain ID="SD_International_CCSs"/><RoleList> <Role Type="permisRole"

Value="LongTerm-CCS"/> </RoleList> <Delegate Depth="0"/> <SOA ID="PERMISDomain_UAM"/> <Validity/>

</RoleAssignment> </RoleAssignmentPolicy> <TargetPolicy> <TargetDomainSpec ID="Students">

<Include LDAPDN="ou=Students,o=PERMISDomain, c=C"/>

</TargetPolicy>

<ActionPolicy> <Action Name="disclose" Args="role value"/> </ActionPolicy> <TargetAccessPolicy> <TargetAccess>

<RoleList> <Role Type="permisRole"

Value="LongTerm-CCS"/></RoleList><TargetList> <Target Actions="disclose">

<TargetDomain ID="Students"/> </Target></TargetList><IF> <AND>

<Substrings> <Arg Name="role" Type="String"/> <Constant Type="String"

Value="studentRole"/></Substrings><Substrings> <Arg Name="value" Type="String"/> <Constant Type="String"

Value="ERASMUS"/></Substrings>

</AND></IF>

</TargetAccess> </TargetAccessPolicy></X.509_PMI_RBAC_Policy>



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


Architectural elements and Policies:Integration Policies - Conversion

<PolicySet xmlns="..." xmlns:xsi="http://www..."PolicySetId="GlobalConversionPolicy" PolicyCombiningAlgId="..."> <Target> <Actions>

<Action> <ActionMatch MatchId="...:string-equal"> <AttributeValue DataType="...#string">translate

</AttributeValue> <ActionAttributeDesignator AttributeId="..:action"

DataType="...#string"/> </ActionMatch></Action>

</Actions> </Target> <PolicySet PolicySetId="PERMISDomainConversionPolicy" PolicyCombiningAlgId="..."> <Target>

<Subjects> <Subject>

<SubjectMatch MatchId="...:string-equal"> <AttributeValue DataType="...#string">

cn=UAM,o=PERMISDomain,c=C </AttributeValue><SubjectAttributeDesignator AttributeId="...:external:SOA" DataType="...#string"/></SubjectMatch>

</Subject></Subjects>

</Target>

<Policy PolicyId="urn:ccs:SimplePolicy1" RuleCombiningAlgId="..."><Target/><Rule RuleId="PERMISDomainSimpleRule1" Effect="Permit"> <Target> <Resources>

<Resource> <ResourceMatch MatchId="...:string-equal"> <AttributeValue DataType="...#string">

studentRole </AttributeValue> <ResourceAttributeDesignator

AttributeId="...:resource-id"DataType="...#string"/>

</ResourceMatch> <ResourceMatch MatchId="...:string-equal"> <AttributeValue DataType="...#string">

ERASMUS </AttributeValue> <ResourceAttributeDesignator

AttributeId="...:value"DataType="...#string"/>

</ResourceMatch></Resource>

</Resources> </Target></Rule><Obligations> <Obligation ObligationId="urn:ccs:Obligation1" FulfillOn="Permit"> <AttributeAssignment DataType="...#string"

AttributeId="urn:saml:attribute:role:student">ERASMUS

</AttributeAssignment> </Obligation></Obligations>

</Policy> </PolicySet></PolicySet>


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


Design Alternatives: Alternative 1Pull 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


Design Alternatives: Alternative 1 Pull model

Target SDHome SD

EU

X.509 PKC

EAPOL

EAP-TLS

DIAMETER-EAP PI

PDP

translateNASREQattributes

attributes

authenticateuser

EAP-SUCCESS

LDAP

UAM NAP AAAPDPLDAP SA

XACMLResourceAccessPolicy

SAMLRequest

AttributeQuerysubject

LDAPQu...

SAMLRequest

XACMLAuthZDecisionQXACMLRequest

subject

res. action

environ.attrs.

SAMLResponse

XACMLAuthZDecSt.XACMLResponse

result obligs.

CCS

SAMLReq….

SAMLRes.

AttributeStattrs

SAMLRes.WrappedSt

Attributes

LDAPResAttributes Disclosure

Query

DisclosureResponse

get userACs

PERMISDisclosure

Policy

XACMLConversion

Policy

PISOAP

PERMIS API


Design Alternatives: Alternative 2Push 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


Design Alternatives: Alternative 2Push model based on SAML Attributes

Home SD

HTTPS LDAP

authenticateuser

EU UAM LDAP

X.509 PKC

LDAPQu...

LDAPResAttributes

PDP

DisclosureQuery

DisclosureResponse

Target SD

AAACCS

SAMLRes.AttributeSt

attrs

SAMLRequest

XACMLAuthZDecisionQXACMLRequest

subject

res. action

environ.attrs.

PERMIS API

SOAP-TLS

XACMLConversion

Policy

PERMISDisclosure

Policy

SAMLReq

ConversionQuery

WrappedSt.Cred.

º


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


Design Alternatives: Alternative 3 Push model based on Attribute Certs.

Target SDHome SD

EU

X.509 PKC

HTTPS

PEAPv2

PI

PDP

authenticateuser

LDAP

UAM NAP AAAPDPLDAP

XACMLResourceAccessPolicy

LDAPQu...

CCS

SAMLRes.

AttributeStattrs

LDAPResAttributes Disclosure

Query

DisclosureResponse

get userACs

PERMISDisclosure

Policy

XACMLConversion

Policy

PI

PERMIS API

X.509 ACs

X.509 PKC + X.509 ACs

SAMLReq

ConversionQuery

WrappedSt.Cred.

º

… rest ofauthorization

process ...


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)

Thanks for your attention

Questions?

Gabriel López Millá[email protected]

A Heterogeneous Network Access Service based on PERMIS and SAML Gabriel López Millán...

Documents

Transcript of A Heterogeneous Network Access Service based on PERMIS and SAML Gabriel López Millán...