The EC PERMIS Project
David Chadwick
[email protected]
Traditional Applications
• Authentication and Authorisation are Internal to the Application
UserName/
Password Lists
Multiple passwords
Multiple usernames
Confusion!!
Access
Control Lists
Multiple Administrators
High cost of administration
No overall Security Policy
Enter PKI
• Authentication is External to the Application
Access
Control Lists
Digital Application
Signature Gateway
One password or pin
to access private key
Happy Users!
Public Key Infrastructure
Multiple Administrators
High cost of administration
No overall Security Policy
Enter PMI
• Authentication and Authorisation are External to the Application
Digital Application
Signature Gateway
One password or pin
to access private key
Happy Users!
Fewer Administrators
Lower cost of admin
Overall Security Policy
Application
Public Key Infrastructure
Privilege Management
Infrastructure
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 Point
X.812|ISO 10181-3 Access Control Framework
User’s Site
Target Site
Initiator Submit Internet
Access
Request
AEF
Decision
Request
Present
Access
Request
Target
Decision
ADF
AEF= application dependent
Access control Enforcement Function
ADF= application independent
Access control Decision Function
PERMIS API System Structure
Initiator
Retrieve
Role ACs
(push)
Submit
Access
Request
Authentication
Service
AEF
Decision
Request
Decision
Present
Access
Request
Target
The PERMIS PMI API
PERMIS API
Implementation
LDAP Retrieve Policy
Directories and Role ACs (pull)
ADF
PKI
Integration with the GRID PKI
PKI
User
TLS
Access
Request
Check
Signature
GRID Appln
gateway
Pass DN
Grant/
+ Access
Deny
Request
The PERMIS PMI API
PERMIS API
Implementation
LDAP Retrieve Policy
Directories and Role ACs (pull)
ADF
Present
Access
Request
Target
Integration with the CAS
CAS
Server
CAS
Policy DB
Capability
CAS containing
request attributes/roles
Access
Request
User
with
Capability
PKI
Check signature
on Capability
GRID Appln
gateway
Decision
Request +
attributes/roles
Grant/
Deny
The PERMIS PMI API
LDAP
Directory
PERMIS API
Implementation ADF
Retrieve Policy
Present
Access
Request
Target
Integration with Shibboleth
Handle
Server
WAYF
Resource Gateway
4. Handle
SHIRE
5.Handle
SHAR
User
Target
8. Att
or AC
9.Grant/Deny
The PERMIS PMI API
AA
Server
PERMIS API
Implementation
LDAP Policy
ADF
Integration with A-Select
Local
A-Select
Server
Local
Authentication
Service
Providers
Remote
Authentication
Service
Providers
UDB
Initiator
Submit
Access
Request
A-Select
Agent
Present
Access
AEF
Request
Decision
Grant/Deny
Request
The PERMIS PMI API
PERMIS API
ADF
Implementation
LDAP
Retrieve Policy
Directories
and Role ACs (pull)
Target
PKI
Integration with Username/PW over SSL
UN/PW/DN
DB
User Username/PW
Over SSL
User’s Roles/
Attributes
Application gateway
with SSL server cert
DN+
Action
Target
Grant/
Deny
The PERMIS PMI API
PERMIS API
Implementation
LDAP Retrieve Policy
Directories and Role ACs (pull)
ADF
PKI
Distributed Management
Entities Involved
LDAP
Directory
Attribute Certificates
Push Mode
Application Gateway
LDAP
Directory
The PERMIS PMI API
Site based SOAs
PERMIS API
Pull Mode Implementation
LDAP
Directory
ADF
Policy
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, 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)