Wednesday, June 03, 2015 © 2001 TrueTrust Ltd1 PERMIS PMI David Chadwick.

Tuesday, April 18, 2023

© 2001 TrueTrust Ltd 1

PERMIS PMI

David Chadwick



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



AZN API System Structure

Initiator Target

AEF

AuthenticationService

AuthenticationMechanism

AZN API

ADFInitiatorSecurity Attributes

Access ControlPolicy Rules

AZN APIImplementation



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 meta rules that govern the creation of the Privilege Policy (Access Control Policy Rules)

• 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 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 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• Published by XML.org at www.xml.org



An Example Policy - the Header

<?xml version="1.0" encoding="UTF-8"?><!DOCTYPE X.509_PMI_RBAC_Policy SYSTEM "file://localhost/C:/research/permis/

policy7.dtd"><X.509_PMI_RBAC_Policy

OID="1.2.826.0.1.3344810.6.0.6">



Role Assignment 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



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>



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 Value=“Tenderer”/><SupRole Value=“TenderClerk”/>

</RoleSpec> </RoleHierarchyPolicy>

TenderOfficer

TenderClerkTenderer



An Example SOA Policy

<SOAPolicy><SOASpec ID="Salford" LDAPDN="cn=David Hunter, ou=computing, dc=salford, dc=gov, dc=uk"/>

<SOASpec ID="BSI" LDAPDN="o=bsi,c=gb"/>

</SOAPolicy>



An Example Role Assignment Policy

<RoleAssignment> <SubjectDomain ID="Employees"/>

<Role Type=”permisRole" Value="TenderOfficer"/> <Delegate Depth="0"/> <SOA ID="Salford"/> <Validity> <Absolute Start="2001-09-21T17:00:00"/> </Validity> </RoleAssignment>



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



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



An Example Target Policy

<TargetPolicy> <TargetDomainSpec ID="TenderStore">

<Include LDAPDN="cn=Tender Store, ou=computing, dc=salford,dc=gov,dc=uk"/>

</TargetDomainSpec> </TargetPolicy>



An Example Action Policy

<ActionPolicy> <Action Args="TenderNo"

Name="Write" /> <Action Args="TenderNo" Name="Read"/> <Action Args="TenderNo"

Name="Delete"/> </ActionPolicy>



An Example Target Access Policy

<TargetAccess><RoleList>

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



An Example Condition Statement

<IF><EQ>

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

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

LocalOrUTC=local Start=2001-06-00 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

• Four Simple Calls: Constructor for API, GetCreds, Decision and Shutdown

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

• Constructor– Pass the name of the administrator, the OID of

the policy and the URLs of the LDAP repositories– API Object reads in the Policy AC and verifies its

signature and OID



API State Transition Diagram

Initialised

No API Object

Subject KnownConstruct

GetCreds

Shutdown

Decision

GetCreds



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

• Shutdown– 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

Wednesday, June 03, 2015 © 2001 TrueTrust Ltd1 PERMIS PMI David Chadwick.

Documents

Transcript of Wednesday, June 03, 2015 © 2001 TrueTrust Ltd1 PERMIS PMI David Chadwick.