Shintau And VPMan proejcts (David Chadwick)

1

30 June 2008 JISC Federated Access Future Directions 1

Shintau and VPMan

David ChadwickInformation Systems Security Research

GroupUniversity of Kent


What is the ISSRG’s expertise?

• To research and develop open source software that provides fine grained access control based on user specified policies

• WHY?


Traditional Applications• Authentication and Authorisation are Internal to

the Application

UserName/Password Lists

AccessControl Lists

Multiple passwordsMultiple usernames

Confusion!! Multiple AdministratorsHigh cost of administrationNo overall Security Policy

APPLICATION


Enter Single Sign On• Authentication is External to the Application• But Authorisation is still mainly internal

– e.g. ACLs

AccessControl Lists

One password or pinfor Authentication

Happy Users! Multiple AdministratorsHigh cost of administrationNo overall Security Policy

Public Key Infrastructure

SSOMiddleware

e.g. Shibboleth

APPLICATION


Enter Privilege Management• Authentication and Authorisation are External to

the Application

One password or pinfor Authentication

Happy Users!Fewer AdministratorsLower cost of adminOverall Security Policy

Public Key Infrastructure

ApplicationFederationMiddleware

Privilege ManagementInfrastructure


Privilege ManagementWhich Access Control Model to Use ?

• DAC is not scalable, MAC is too inflexible• In order to provide scalability for federations,

Virtual Organisations and Grids we use the Role Based Access Control Model RBAC (or the Attribute Based Access Control Model ABAC to be more precise)

• What’s the difference?• Roles can be delegated between users e.g.

team leader, VO member etc.• Attributes are more general and cannot usually

be delegated e.g. your degree, your age, your sex etc

• But both can be used for access controls

2


Hierachical RBAC/ABAC• Permissions are allocated to roles/attributes• Superior roles/attributes inherit privileges of subordinate

roles/attributes• Users are assigned role/attribute memberships• Members acquire the permissions of their attributes/roles• Benefits

– SecurityRemove a user’s roles andall privileges are gone

– ManageabilityUsers change more frequently than roles

– ScalabilityNo of roles usuallymuch less than noof users

User-Role assignments Role-Privilege (UA) assignments (PA)


Why is RBAC/ABAC so good?• We can distribute the user-attributes/role

assignments to a set of trusted Attribute Authorities – entities who have close relationships with users and know which attributes they possess– each university knows who are its students and who

are its staff– the GMC knows who are GPs

• We can allow resource owners to keep tight control of their own resources by saying which roles/attributes have which permissions– students can access the b/w laser printer– staff can access the colour laser printer– GPs can access the patient records


Applying this to Federations• Shibboleth

– Cross-institutional authentication & authorization protocol– Supports single sign-on via user’s home site– Shibboleth Identity Provider authenticates user and

provides user’s attributes to Shibboleth Service Provider• PERMIS, a policy driven fine grained PMI

– extends Shibboleth Service Provider with– Policy controlled RBAC decision making based on

dynamically evaluated conditions and user attributes provided by Shibboleth Identity Provider

– Mod_permis plugin to Apache makes external authzcallout to PERMIS

– Can be used in conjunction with mod_shib or without it to provide PERMIS protection to Apache web sites


Applying this to Grids

• VOMS (the Virtual Organisation Management System) is a system developed by INFN to manage the assignment of VO roles to users

• PERMIS is a PMI system developed by the ISSRG to provide policy driven fine grained access controls based on RBAC/ABAC

• The JISC funded VPMan project is integrating VOMS with PERMIS for the National Grid Service, which uses both OMII and GlobusToolkit


PERMIS

User Globus Client

VOMS

GridResourceGT4 PEP

CVS PDP

AR

AR=Attribute RepositoryCVS = Credential Validation ServicePDP = Policy Decision PointPEP= Policy Enforcement PointSOA = Source of Authority

Target SOA

VOManager

Environment ObligationsService

VomsProxyInit

PERMISPolicy

SAMLAssertion

VOMS PERMIS GT430 June 2008 JISC Federated Access Future Directions 12

PERMIS

User OMII Client

VOMS

GridResourceOMII PEP

CVS PDP

AR

AR=Attribute RepositoryCVS = Credential Validation ServicePDP = Policy Decision PointPEP= Policy Enforcement PointSOA = Source of Authority

Target SOA

VOManager

Environment

PERMISPolicy

SAMLAttributeAssertion

OGF SAML Callout

VOMS PERMIS OMII

3


PERMIS Policy Editor


Policy Wizard


Natural Language Policy Output


Controlled Natural Language Policy Input is being developed


But what are the limitations of VPMAN?

• Users typically have roles and attributes assigned by multiple AAs, not just by VOMS.– e.g. Shibboleth IDPs

• Thus VPMan on its own cannot be a complete solution

• The first attempt at a multi-AA solution is the GridShib Project from Globus

• This allows Shibboleth attributes and VOMS attributes to be combined together

• We added PERMIS in the GridShibPERMISproject to allow fine grained access control


X.509Authentication

GT4 PEP

Grid Client

GridShibPIP

GridShibPERMISContext Handler

Shib AttributeAuthority

GridResource

Request

DistinguishedName Binder

User Attributes

Shibboleth Identity Provider

Globus Toolkit

PERMISCVS

PERMIS PDP

PERMIS

GridShibPERMIS

VOMS

4


Limitations of GridShib

• Only supports two AAs – Grid AA e.g.VOMS and Shibboleth

• Requires user to have an X.509 certificate for authentication (can’t use Shibboleth authn)

• Scalability problem as requires each user DN to be mapped into the Shibboleth ID in Distinguished Name Binder

• Initial version only supports one Shibboleth IDP• A more flexible solution is needed, enter Shintau


Shib-Grid Integrated Authorization(Shintau)

• Objective is to allow users to aggregate attributes from an arbitrary number of AAsfor use in a single authorisation session

• To be able to use this aggregation in federations, grids, VOs etc– i.e. not tied to any specific application or

technology


Attribute Aggregation• Users typically have attributes issued by multiple

authorities– e.g. University issues degree certificate, General Medical

Council issues doctor certificate, Employer issues employee certificate

• Similar to the multiple plastic cards you carry around in your wallet today

• Users may need to provide several of these certificates in order to be granted access but the user is known by different names at each authority

• So how can a service provider know that all these electronic tokens belong to the same person?

• Assumption: Only the user knows who all his AAs are therefore the user must be in control of linking them together


IdP 1

IdP 2

LinkingService

12

34

5

67

Linking Service• Allows the user to link his various issuing authorities together whilst retaining

his privacy• Linking service does not know who the user is or what attributes he has• Authorities do not know which other authorities the user is related to

UserX, Attr1, RegLoA, PID 1:LS

UserA, Attr2, RegLoA, PID 2:LS

UserZ, IdP1:PID 1:LLoA1, IdP2:PID2:LLoA2

Storage Requirements


UserID PId IdP LinkLoAFred A=123 Airmiles.com 1Fred EduX=u23@kent

.ac.ukKent.ac.uk 2

Mary ABC=456 XYX Co 1Fred uid=123345 Cardbank.com 3

UserID SP IDPFred Books.co.uk Kent.ac.uk

Fred Books.co.uk Cardbank.com

Mary Books.co.uk XYX Co

Fred Cardbank.com *

Fred Compstore.com Cardbank.com

Fred Compstore.com Airmiles.com

Fred * Kent.ac.uk

Link ReleasePolicy Table

Linking Table


Use of LoA• User first registers at an IdP with a

Registration LoA• Thereafter each act of Authn can only be at

the same or lower Session LoA• Linking Service optionally records the Session

LoA at linking time as the Linking LoA• During service requests, Linking Service will

only contact linked IdPs with Linking LoAs.GE. than the current Session LoA

• This prevents a user claiming an attribute with a higher Session LoA than Registration LoA

5


IdP 1

Service Provider

1. Service Request

2. User redirected to chosen IdP

4. IdP 1’s attributes +

Referral to Linking Service

3

User Authn

LinkingService

5. SP follows referral

6. Referrals to linked IdPs 2 and 3

IdP 3

IdP 27. SP follows referral

9. SP follows referral8. IDP2’s attributes

10. IDP3’s attributes

Service Provider Attribute Aggregation


IdP Direct SP aggregation with IDWSF Id Mapping

SP IdP(a) LS IdP(b)User

5. IDWSF Identity Mapping Request (EPR1 + AuthnAssertion) +

8. IDWSF Identity Mapping Response

<samlp:AttributeQuery>

7. IDWSF Identity Mapping Request (EPR 2 + Authn Assertion)

6. IDWSF Identity Mapping Response (EPR2)

+ <samlp:AttributeQuery>

+ <samlp:Response>

+ <samlp:Response>

9. Grant/Deny

2. <samlp:AuthnRequest>

3. Authentication

4. <samlp:Response> (Authn Assertion ,EPR1,

Attribute Statement)

1. User Requests Service


IdP 1

Service Provider

1. Service Request

2. User redirected to chosen IdP

4. IdP 1’s attributes +

Referral to Linking Service

3

User Authn

LinkingService

5. SP follows referral

Linking Service Attribute Aggregation

10. Complete set of attributes

IdP 3IdP 2

6. LS re

quests

attributes

7. Attri

butes 8. LS requests

attributes

9. Attributes


Integrating Shintau with Shibboleth

• The user will authenticate as now with his chosen IDP

• The Shibboleth IDP code will be enhanced to return the authentication assertion, attribute assertion and in addition a referral to the user’s linking service

• Mod_permis will be modified to make outgoing calls to the linking service to pull in the user’s other attributes, then all of these will be passed to PERMIS


Integrating Shintau with VPMan

• Cannot use normal proxy certificates any longer (but some users don’t like them anyway)

• The user will need to authenticate to an enhanced Shibboleth IDP and we will need the user’s authentication assertion and referral to be passed to the Shintau code which can then pull the remaining attributes from the linked AAs

• This is the subject of the SARoNGS project that you will hear from next


Conclusions• Attribute Based Access Controls provide great

flexibility and scalability• It allows the assignment of roles and attributes

to be distributed around a federation/VO/grid whilst allowing the resource owner to keep tight control over his resources

• Policy based authorisation provides fine grained control without losing scalability

• By integrating grids with campus information systems through common technology we provide users with SSO and administrators with less management overheads

6


Any Questions??

Shintau And VPMan proejcts (David Chadwick)

Business

Transcript of Shintau And VPMan proejcts (David Chadwick)