4 June 2002© 2001-2 TrueTrust Ltd1 PMI Components Oleksandr Otenko Research Student ISSRG, University of Salford

4 June 2002 © 2001-2 TrueTrust Ltd 1

PMI Components

Oleksandr OtenkoResearch StudentISSRG, University of Salford

http://sec.isi.salford.ac.uk/


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


X.812|ISO 10181 Access Control Framework

ADF

Initiator TargetSubmitAccessRequest

PresentAccessRequest

DecisionRequest

Decision

AEF


ADF API

ADF API

DecisionRequest

Decision

AEF

ADF

Examples:OpenGroup AZN APIIETF GAA APIPERMIS API

Application specific

Application independent


PERMIS API System Structure

ADF

The PERMIS PMI API

Initiator Target

SubmitSignedAccessRequest

PresentAccessRequestDecision

Request Decision

LDAPDirectory

Retrieve Policy and Role ACs

AEF

AuthenticationService

ApplicationGateway

PERMIS API Implementation

PKI


PERMIS PMI Components

• Privilege Policy Schema/DTD– This defines the rules that govern the creation of

the Privilege Policy (Access Control Policy)

• Privilege Allocator– This tool allows an administrator to create and

sign Attribute Certificates, including a Policy AC (this is a signed version of the Privilege Policy), and store them in an LDAP directory

• The PERMIS PMI Implementation– This grants or denies Initiators access to

resources, based on the Privilege Policy and the ACs of the Initiator. The ADF is accessed via the PERMIS API


Application Specific Components

• The Access Enforcement Function– Its task is to ensure the Initiator is authenticated by the PKI,

then to call the ADF, and give access to the target if allowed

• The PKI– Any standard conforming PKI can be used

• Java PKCS#11-like Interface to the PERMIS PMI• The Privilege Policy in XML

– This must be written according to the schema/DTD

• LDAP Directory– To store the Policy and Initiator ACs


Permis RBAC

UsersRoles Targets/

Actions

SubjectPolicy

+SOA

Policy

BillMaryFredJane

Manager

Project Leader

Team Leader

Employee

RoleHierarchy

Policy

RoleAssignment

Policy +

DelegationPolicy

TargetPolicy

+ActionPolicy

Salary IncreasesAccess Building

Delete FilesRead Files

Sign Orders

Role Specification

Policy (Target Access Policy )


PERMIS X.509 PMI RBAC Policy

• Role Based Access Control Policy written in XML• Initiators are given Role Assignment ACs• A role is loosely defined as any Attribute Type and

Attribute Value• Role values can form a hierarchy, where superiors

inherit the privileges of their subordinates e.g. CTO>PM>TL>TM

• ACs can be issued by any trusted AA• Access is based on the Roles


An Example Set of Roles

CharteredArchitect

ISO 9000

Chief Architect

SOA= Royal College of Architects

SOA= BSIArchitect

JuniorArchitect

SOA= CompanyManaging Director


Role Assignment Policy Components

• SOA Policy– Specifies who is trusted to issue ACs

• Subject Policy• Role Hierarchy Policy• Role Assignment Policy


Subject Policy

UsersRoles Targets/

Actions

SubjectPolicy

+SOA

Policy

BillMaryFredJane

Manager

Project Leader

Team Leader

Employee

RoleHierarchy

Policy

RoleAssignment

Policy +

DelegationPolicy

TargetPolicy

+ActionPolicy



Sign Orders

Role Specification


– Specifies subject domains based on LDAP subtrees


An Example Subject Policy

<SubjectPolicy> <SubjectDomainSpec ID="Companies">

<Include LDAPDN="dc=myorg, dc=com"/> <Include LDAPDN="dc=co,dc=uk"/> </SubjectDomainSpec> <SubjectDomainSpec ID="Employees">

<Include LDAPDN="dc=salford,dc=gov,dc=uk"/> </SubjectDomainSpec> </SubjectPolicy>


Role Hierarchy Policy

UsersRoles Targets/

Actions

SubjectPolicy

+SOA

Policy

BillMaryFredJane

Manager

Project Leader

Team Leader

Employee

RoleHierarchy

Policy

RoleAssignment

Policy +

DelegationPolicy

TargetPolicy

+ActionPolicy



Sign Orders

Role Specification


– Specifies hierarchy of role values


An Example Role Hierarchy Policy

<RoleHierarchyPolicy><RoleSpec Type=“permisRole” OID=“1.2.826.0.1. 3344810.1.1.14”>

<SupRole Value=“TenderOfficer”><SubRole

Value=“TenderClerk”/> </SupRole>

<SupRole Value=“Tenderer”/><SupRole Value=“TenderClerk”/>

</RoleSpec> </RoleHierarchyPolicy>

TenderOfficer

TenderClerkTenderer


Role Assignment Policy

UsersRoles Targets/

Actions

SubjectPolicy

+SOA

Policy

BillMaryFredJane

Manager

Project Leader

Team Leader

Employee

RoleHierarchy

Policy

RoleAssignment

Policy +

DelegationPolicy

TargetPolicy

+ActionPolicy



Sign Orders

Role Specification


– Says which roles can be given to which subjects by which SOAs, with which validity times and whether delegation is allowed


An Example Role Assignment Policy

<RoleAssignment>

<SubjectDomain ID="Employees"/>

<RoleList>

<Role Type=”permisRole" Value="TenderOfficer"/>

</RoleList>

<Delegate Depth="0"/>

<SOA ID="Salford"/>

<Validity>

<Absolute Start="2001-09-21T17:00:00"/>

</Validity>

</RoleAssignment>


Target Access Policy Components

• 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


Target Access Conditions

• A condition comprises:– a comparison operator– the LHS operand(variable), described by its source, name and

type, and• variable source is the action or the environment• Eg. Source Read action, Name filename, Type string• Eg. Source environment, Name time of day, Type time

– a series of one or more variables or constant values against which the LHS operand is to be compared

• Conditions may be combined using AND, OR, NOT


Target Access Policy

UsersRoles Targets/

Actions

SubjectPolicy

+SOA

Policy

BillMaryFredJane

Manager

Project Leader

Team Leader

Employee

RoleHierarchy

Policy

RoleAssignment

Policy +

DelegationPolicy

TargetPolicy

+ActionPolicy



Sign Orders

Role Specification


– Specifies which roles are needed to access which targets for which actions, and under what conditions


An Example Target Access Policy

<TargetAccess><RoleList>

<Role Type=”permisRole" Value="TenderOfficer"/> </RoleList> <TargetList> <Target Actions=”Delete"> <TargetDomain ID="TenderStore"/> </Target> </TargetList></TargetAccess>


An Example Condition Statement

<IF><EQ>

<Environment Parameter="TimeOfAccess" Type="Time"/>

<Constant Type="TimePeriod" Value= "DaysOfWeek=0111110 End=2001-10-01

LocalOrUTC=local Start=2001-06-01 TimeOfDay=T090000/T170000"/>

</EQ> </IF></TargetAccess>


Creating Your Own Policy

• If an XML expert, simply use your favourite text editor

• Or use an XML tool such as Xeena from IBM Alphaworks


The Privilege Allocator

• A tool for creating Attribute Certificates


The PERMIS API

• Three Simple Methods: getCreds, decision, finalize and a Constructor

• Written in Java and based on the OpenGroup’s AZN API

• Constructing the API object– Pass the name of the administrator, the

OID of the policy and the URLs of the LDAP repositories

– During construction, the API reads in the Policy AC and verifies its signature and OID


The PERMIS API (cont)• GetCreds

– Pass the authenticated name (LDAP DN) of the subject

– Pull mode, GetCreds retrieves the subject’s ACs– Push mode, ACs are passed to GetCreds– ACs are validated and roles extracted

• Decision– Pass the target name, the action, and the

parameters of the subject’s request– Decision checks the request against the policy

and returns Granted or Denied

• Finalize– Terminates the use of this policy


PrivilegeAllocator

LDAPdirectory

AttributeCertificates+ ACRLs

SOA

RemoteApplicationUser

PrivilegePolicy

INTERNET

INTRANET

PKI

Certifies

PK Certs+PKCRLs

Authorises

Putting it altogether - Allocating Privileges

LDAPdirectory


Privilege Creation Steps• SOA defines Privilege Policy using

Privilege Allocator• Privilege Policy is stored in LDAP

directory as self signed Attribute Certificate

• SOA allocates privileges to user, in accordance with the Privilege Policy

• SOA can revoke user privileges• SOA can update Privilege Policy


E-CommerceApplication

Server

LDAPdirectory

Privilege Policy ACs + ACRLs +

PK CRLs

RemoteApplicationUser

Digitally SignedRequest (SSL or S/MIME)

Privilege Verifier

INTERNET

INTRANET

Granting User Access

Application Gateway

Accessesusing privilegesgranted the user

LDAPdirectory


Example Applications

• Salford City Council - Electronic Tendering

• Barcelona Municipality - Car Parking Fines

• Bologna Comune - architects submitting building plans

• Electronic Prescription Processing


Thank you!

Alex Otenko

Our site: http://sec.isi.salford.ac.uk/

PERMIS project: http://sec.isi.salford.ac.uk/permis/

Documents

4 June 2002© 2001-2 TrueTrust Ltd1 PMI Components Oleksandr Otenko Research Student ISSRG, University of Salford