the ec permis project david chadwick [email protected]
Post on 19-Dec-2015
216 views
TRANSCRIPT
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
Enter PKI
• Authentication is External to the Application
AccessControl Lists
One password or pinto access private key
Happy Users! Multiple AdministratorsHigh cost of administrationNo overall Security Policy
DigitalSignature
Public Key Infrastructure
ApplicationGateway
Enter PMI
• Authentication and Authorisation are External to the Application
One password or pinto access private key
Happy Users!
Fewer AdministratorsLower cost of adminOverall Security Policy
DigitalSignature
Public Key Infrastructure
ApplicationApplicationGateway
Privilege ManagementInfrastructure
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
ADF
Initiator TargetSubmitAccessRequest
PresentAccessRequest
DecisionRequest
Decision
AEF
ADF= application independentAccess control Decision Function
Internet
Target SiteUser’s SiteAEF= application dependentAccess control Enforcement Function
PERMIS API System Structure
Initiator Target
SubmitAccessRequest
PresentAccessRequestDecision
Request Decision
AEF
AuthenticationService
LDAPDirectories
Retrieve Policy and Role ACs (pull)
PKIADF
The PERMIS PMI APIPERMIS API Implementation
RetrieveRole ACs
(push)
Integration with the GRID PKI
ADF
The PERMIS PMI API
User Target
TLSAccessRequest
PresentAccessRequestPass DN
+ AccessRequest
Grant/Deny
LDAPDirectories
Retrieve Policy and Role ACs (pull)
GRID Applngateway
Check Signature
PERMIS API Implementation
PKI
Integration with the CAS
ADF
The PERMIS PMI API
User Target
AccessRequest
with Capability
PresentAccessRequestDecision
Request +attributes/roles
Grant/Deny
LDAPDirectory
Retrieve Policy
Check signatureon Capability
PERMIS API Implementation
PKI
CASServer
Capabilitycontaining attributes/roles
CASrequest
GRID Applngateway
CASPolicy DB
Integration with Shibboleth
User
LDAP
Target1. User request
HandleServer
Policy
SHAR
SHIRE
WAYF
2.Re-direct to WAYF
3.Re-direct to HS
4. Handle
5.Handle
AAServer
6. AQM
7. ARM with attributes or ACs
Resource Gateway
ADF
The PERMIS PMI APIPERMIS API Implementation
9.Grant/Deny8. Att or AC
Integration with PAPI
User
Authentication
Authentication
Server
Keys
Hcook- Lcook GPoA
GPoA
PoA
Hcook- Lcook PoA
302+ Hcook
302 + data
LDAPDirectories
Retrieve Policy and Role ACs (pull)
PKIADF
The PERMIS PMI APIPERMIS API Implementation
UserDN from cookie+ access request
Granted/denied
Integration with A-Select
ADF
The PERMIS PMI API
Initiator Target1.SubmitAccessRequest
PresentAccessRequest
6.DN +Request Grant/Deny
LDAPDirectories
Retrieve Policy and Role ACs (pull)
AEF
A-SelectAgent
PERMIS API Implementation PKI
Remote Authentication
Service Providers
Local Authentication
Service Providers
LocalA-Select Server
UDB
2.Re-directuser to AS
4.Authenticate3.Re-direct
user to Authserver
5. Provide ticket
Integration with Username/PW over SSL
LDAPDirectories
Retrieve Policy and Role ACs (pull)
PKIADF
The PERMIS PMI APIPERMIS API Implementation
User Application gatewaywith SSL server cert
Username/PWOver SSL
UN/PW/DNDB
DN+Action
Grant/Deny
Target
User’s Roles/Attributes
Distributed ManagementEntities Involved
LDAPDirectory
Policy
ADF
The PERMIS PMI APIPERMIS API Implementation
LDAPDirectory
LDAPDirectory
Attribute Certificates
Target SOA
Site based SOAs
Push Mode
Pull Mode
Application Gateway
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)