The EC PERMIS Project

1
The EC PERMIS Project

• David Chadwick
• d.w.chadwick_at_salford.ac.uk

2
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

• Authentication is External to the Application

Access Control Lists
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.812ISO 10181-3 Access Control Framework
Target Site
Users Site
Initiator
Target
Present Access Request
AEF
Submit Access Request
Internet
Decision Request
Decision
ADF
AEF application dependent Access control
Enforcement Function ADF application
independent Access control Decision Function
8
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
User
Present Access Request
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
Integration with the CAS
CAS Server
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
SHIRE
2.Re-direct to WAYF
4. Handle
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
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
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
Users 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)