1
30 June 2008 JISC Federated Access Future Directions 1
Shintau and VPMan
David ChadwickInformation Systems Security Research
GroupUniversity of Kent
30 June 2008 JISC Federated Access Future Directions 2
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?
30 June 2008 JISC Federated Access Future Directions 3
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
30 June 2008 JISC Federated Access Future Directions 4
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
30 June 2008 JISC Federated Access Future Directions 5
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
30 June 2008 JISC Federated Access Future Directions 6
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
30 June 2008 JISC Federated Access Future Directions 7
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)
30 June 2008 JISC Federated Access Future Directions 8
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
30 June 2008 JISC Federated Access Future Directions 9
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
30 June 2008 JISC Federated Access Future Directions 10
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
30 June 2008 JISC Federated Access Future Directions 11
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
30 June 2008 JISC Federated Access Future Directions 13
PERMIS Policy Editor
30 June 2008 JISC Federated Access Future Directions 14
Policy Wizard
30 June 2008 JISC Federated Access Future Directions 15
Natural Language Policy Output
30 June 2008 JISC Federated Access Future Directions 16
Controlled Natural Language Policy Input is being developed
30 June 2008 JISC Federated Access Future Directions 17
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
30 June 2008 JISC Federated Access Future Directions 18
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
30 June 2008 JISC Federated Access Future Directions 19
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
30 June 2008 JISC Federated Access Future Directions 20
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
30 June 2008 JISC Federated Access Future Directions 21
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
30 June 2008 JISC Federated Access Future Directions 22
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
30 June 2008 JISC Federated Access Future Directions 23
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
30 June 2008 JISC Federated Access Future Directions 24
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
30 June 2008 JISC Federated Access Future Directions 25
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
30 June 2008 JISC Federated Access Future Directions 26
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
30 June 2008 JISC Federated Access Future Directions 27
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
30 June 2008 JISC Federated Access Future Directions 28
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
30 June 2008 JISC Federated Access Future Directions 29
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
30 June 2008 JISC Federated Access Future Directions 30
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
30 June 2008 JISC Federated Access Future Directions 31
Any Questions??
Top Related