21
The EC PERMIS Project David Chadwick [email protected] k

The EC PERMIS Project David Chadwick [email protected]

  • View
    216

  • Download
    0

Embed Size (px)

Citation preview

The EC PERMIS Project

David Chadwick

[email protected]

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)