210 likes | 227 Views
The EC PERMIS project aims to overcome challenges such as multiple passwords and usernames, high administration costs, and lack of overall security policy with a robust policy-based access control system. PERMIS uses X.509 attribute certificates and can work with various authentication systems.
E N D
The EC PERMIS Project David Chadwick d.w.chadwick@salford.ac.uk
UserName/ Password Lists Access Control Lists Traditional Applications • Authentication and Authorisation are Internal to the Application Multiple passwords Multiple usernames Confusion!! Multiple Administrators High cost of administration No overall Security Policy
Enter PKI Access Control Lists • Authentication is External to the Application Application Gateway Digital Signature Public Key Infrastructure One password or pin to access private key Happy Users! Multiple Administrators High cost of administration No overall Security Policy
Enter PMI • Authentication and Authorisation are External to the Application Application Gateway Digital Signature Application Public Key Infrastructure One password or pin to access private key Happy Users! Privilege Management Infrastructure Fewer Administrators Lower cost of admin Overall Security Policy
What PERMIS is not • It is not an AAA system • It does not help in authenticating users, or accounting • It does not try to replace PKI, Shibboleth or other institution or inter-realm based authentication mechanisms • It is not a protocol for carrying authentication/authorisation tokens e.g. SAML, PAPI, HTTP
What PERMIS is • It is a policy based authorisation system, a PMI, that uses X.509 attribute certificates to hold roles/attributes • It can work with any and every authentication system (Shibboleth, PAPI, Kerberos, PKI, username/PW, etc.) • Given a username, a target and an action, it says whether the user is granted or denied access based on the policy for the target • The policy is role/attribute based i.e. users are given roles/attributes. Roles/attributes are given permissions to access targets • The policy is written in XML, is similar to XACML, but simpler and produced earlier • It can work in push or pull mode (attributes are sent to PERMIS, or PERMIS fetches them itself)
Compliance checker/Policy Enforcement PointX.812|ISO 10181-3 Access Control Framework User’s Site Target Site AEF= application dependent Access control Enforcement Function Initiator Target AEF Present Access Request Submit Access Request Internet Decision Request Decision ADF ADF= application independent Access control Decision Function
The PERMIS PMI API PERMIS API Implementation ADF PKI LDAP Directories Retrieve Policy and Role ACs (pull) PERMIS API System Structure Authentication Service Submit Access Request Initiator Present Access Request Target AEF Decision Request Retrieve Role ACs (push) Decision
Integration with the GRID PKI PKI Check Signature TLS Access Request Present Access Request User GRID Appln gateway Target Pass DN + Access Request Grant/ Deny The PERMIS PMI API PERMIS API Implementation ADF LDAP Directories Retrieve Policy and Role ACs (pull)
CAS Server Integration with the CAS CAS Policy DB PKI Capability containing attributes/roles CAS request Check signature on Capability Access Request with Capability GRID Appln gateway User Present Access Request Target Decision Request + attributes/roles Grant/ Deny The PERMIS PMI API PERMIS API Implementation ADF LDAP Directory Retrieve Policy
Integration with Shibboleth WAYF Handle Server Resource Gateway 3.Re-direct to HS 4. Handle 2.Re-direct to WAYF SHIRE User 5.Handle 1. User request Target SHAR 8. Att or AC 6. AQM 9.Grant/Deny 7. ARM with attributes or ACs AA Server The PERMIS PMI API PERMIS API Implementation ADF LDAP Policy
Authentication 302 + data GPoA PoA 302+ Hcook The PERMIS PMI API PERMIS API Implementation ADF Integration with PAPI Authentication Server Keys User Hcook- Lcook GPoA Hcook- LcookPoA UserDN from cookie + access request Granted/ denied PKI LDAP Directories Retrieve Policy and Role ACs (pull)
Local A-Select Server UDB Integration with A-Select Local Authentication Service Providers Remote Authentication Service Providers 2.Re-direct user to AS 3.Re-direct user to Auth server 4.Authenticate A-Select Agent 5. Provide ticket Present Access Request 1.Submit Access Request Initiator Target AEF 6.DN + Request Grant/Deny The PERMIS PMI API PERMIS API Implementation ADF PKI LDAP Directories Retrieve Policy and Role ACs (pull)
The PERMIS PMI API PERMIS API Implementation ADF PKI LDAP Directories Retrieve Policy and Role ACs (pull) Integration with Username/PW over SSL UN/PW/DN DB User Application gateway with SSL server cert Username/PW Over SSL Target DN+ Action Grant/ Deny User’s Roles/ Attributes
Distributed ManagementEntities Involved LDAP Directory Push Mode Attribute Certificates Application Gateway LDAP Directory The PERMIS PMI API PERMIS API Implementation ADF Site based SOAs Pull Mode Policy LDAP Directory Target SOA
PERMIS Trust Model • The Target/Resource is the root of trust (Source Of Authority SOA) for access to itself • The Target is configured with its SOA name at start up • The Policy is signed by the SOA (Permis checks this) • The SOA says in the policy which remote SoAs it trusts to allocate roles • The SOA says what roles they can allocate • The SOA says what access rights are given to each role • The remote SoAs authenticate the users and allocate roles to them
PERMIS Policy Components • Subject Policy • Specifies subject domains based on LDAP subtrees • Role Hierarchy Policy • Specifies hierarchy of role values • SOA Policy • Specifies who is trusted to issue ACs • Role Assignment Policy • Says which roles can be given to which subjects by which SOAs, with which validity times and whether delegation is allowed
PERMIS Policy Components (cont) • Target Policy • Specifies the target domains covered by this policy, using LDAP subtrees • Action Policy • Specifies the actions (operations) supported by the targets, along with their allowed operands • Target Access Policy • Specifies which roles are needed to access which targets for which actions, and under what conditions
Current Applications • E-tendering at Salford City Council • E-planning at Bologna Comune • Access to car parking fines database at Barcelona City • Electronic Transfer of Prescriptions at University of Salford
What PERMIS is not • It is not an AAA system • It does not help in authenticating users, or accounting • It does not try to replace PKI, Shibboleth or other institution or inter-realm based authentication mechanisms • It is not a protocol for carrying authentication/authorisation tokens e.g. SAML, PAPI, HTTP
What PERMIS is • It is an authorisation system, that uses X.509 attribute certificates to hold roles/attributes • It can work with any and every authentication system (Shibboleth, PAPI, Kerberos, PKI etc.) • Given a username(DN), a target and an action, it says whether the user is granted or denied access based on the policy for the target • The policy is role/attribute based i.e. users are given roles/attributes. Roles/attributes are given permissions to access targets • The policy is written in XML, is similar to XACML, but simpler and produced earlier • It can work in push or pull mode (attributes are sent to PERMIS, or PERMIS fetches them itself)