1 / 20

The EC PERMIS Project

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

tamma
Download Presentation

The EC PERMIS Project

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. The EC PERMIS Project David Chadwick d.w.chadwick@salford.ac.uk

  2. 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

  3. 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

  4. 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

  5. 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

  6. 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)

  7. Compliance checker/Policy Enforcement PointX.812|ISO 10181-3 Access Control Framework User’s Site Target Site Initiator Target AEF Present Access Request Submit Access Request Internet Decision Request Decision ADF AEF= application dependent Access control Enforcement Function ADF= application independent Access control Decision Function

  8. 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

  9. 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)

  10. 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

  11. 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

  12. Local A-Select Server UDB Integration with A-Select Local Authentication Service Providers Remote Authentication Service Providers A-Select Agent Present Access Request Submit Access Request Initiator Target AEF Decision Request Grant/Deny The PERMIS PMI API PERMIS API Implementation ADF PKI LDAP Directories Retrieve Policy and Role ACs (pull)

  13. 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

  14. 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

  15. 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

  16. 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

  17. 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

  18. 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

  19. 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

  20. 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, 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 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)

More Related