installation guide

The Delegation Issuing Service (DIS) User Guide

© Copyright 2005-2006, University of Kent

Document History

Version Date Comments

0.1 9 Sept 2005 First draft by Wensheng

0.2 12 Sept 2005 Updated by Tuan Anh

0.3 14 Sept 2005 Reviewed by David

1.0 15 Sept 2005 First public release

1.1 1 July 2006 Updated with Acceptance Tests for issuing attributes

1.2 24 July 2006 Update the installation instructions

1.3 26 July 2006 Updated with Acceptance Tests for revocation attributes

1.4 14 Aug. 2006 Fix some inconsistencies after validating by Romain

1.5 3 Oct 2006 Add the SearchRequestor parameter, change the parameters in the configuration file using Permis standard parameters.

1.6 24 Oct 2006 Add instruction for using policy stored in a file

1.7 24 Oct 2006 Add support for java 1.5

1.8 22 Feb 2007 Add support for Tomat 5.5

1.9 23 April 2007 Add support for Apache 2.2

2.0 12 August 2008

Using PERMIS v5 policies and Apache http server on Windows (by Linying)

Table of Contents

1

Introduction

The Delegation Issuing Service (DIS) is a web service for issuing attribute certificates on behalf of privilege holders who wish to delegate their privileges to their peers and subordinates. The DIS web service is accessed by DIS web service client applications. A DIS client application may be the end user (e.g. when an application wants to delegate privileges to another application) or may be directly connected to a human user via an appropriate user interface, or may be a trusted server acting as a proxy between human users and the DIS (e.g. the Apache client that we provide in this release).

In our implementation of the DIS, the DIS web service server is a Java component, which is based on the Tomcat application server and the Apache AXIS soap server, and it can be invoked through SOAP calls. For demonstration purposes, our DIS client application is a proxy written in PHP and running on an Apache server. It invokes the DIS web service server – the Java component, via SOAP calls. The human end users access the Apache proxy via a standard web browser, and are authenticated to Apache using their usernames and passwords that are stored in the local LDAP server.

In this user guide, we assume that you have the Tomcat server and the Apache server on two different computers, which are called the DIS server computer and the DIS client computer respectively in this user guide, although you may of course run them both on the same server if you wish.

I. Before you start

You will need to have the following components before you start to install the DIS.

Running systems

The following systems should be installed and working prior to installing the DIS.

On the DIS server computer:

1. A Tomcat application server (version 4.1.x or 5.5. In this demonstration, we use version 5.5).

2. An LDAP server that you have write access to (version 2.2.x of OpenLDAP is recommended). This is needed to hold user X.509 attribute certificates. You need to install an LDAP Server for running the DIS.

3. Java Runtime Environment - required running the Tomcat and DIS Java compo-nent. The version of JRE you need is 1.4. or 1.5 JRE is available from:

http://java.sun.com/.

4. If you use java 1.4, you need to use tomcat 4.1.x for the DIS. If you use java 1.5, you need to use tomcat 5.5

On the DIS client computer:

5. An Apache web server with SSL, PHP, mod_ldap and mod_auth_ldap (Apache version 2.0).

The DIS Installation kit

The Kent DIS installation kit comprises the following items in two packages – the DIS server package and the DIS client package.

In the DIS server package:

1. The DIS library sub directory <dislib>, which contains the Java classes library for the DIS web service server dis.jarand the following support Java library file:

iaik_jce.jar

2. The DIS web service server configuration files sub directory <discfg> which con-tains the following files:

dis.cfg

serialnumber.cfg

3. A DIS web service deployment definition file: disDeploy.wsdd

4. An LDAP ldif file for our demonstration LDAP, which contains all the demon-stration users, role attribute certificates, and the policy certificate data.ldifand an LDAP schema file in the sub directory <disschema>: core.schema This schema file should be used to replace the schema file in your LDAP system.

5. A keystore sub directory <serverSideKeystore>, for the DIS web service server, which contains the following keystore files:

cacert.cer -- root CA certificate, used by the DIS web service server

dis-cert.p12 -- DIS signing key pair, used by the DIS web service server. Its password is “dis123”. This can also be used for by Tomcat SSL configuration as the Tomcat keystore for the testing purposes.

http://java.sun.com/

soa-cert.p12 – this is the singing key of the SOA. You will use it to sign the DIS’s AC in the testing suite. Its password is “l3tM3InNow”.

6. The Installation Cookbook (this document)

In the DIS client package:

7. The DIS Apache client module sub directory <clientSidePHP> which contains the following files:

dis.php

rs1.php

proxysigning.cfg

dis.html

policy.html

username.html

and an image sub directory <images> which contains the following files:

Role.gif

image0.gif

image1.gif

image2.gif

image3.gif

8. A keystore sub directory <clientSideKeystore>, for the DIS web service client, which contains the following keystore files:

httpd-cert.pem -- Apache SSL public key certificate, used by the Apache server

httpd-key.pem -- Apache SSL private key, used by the Apache server

httpd-cert-key.pem – Apache proxy SSL public key certificate and private key file, used by the Apache proxy

cacert.pem -- Apache CA certificate file, used by the Apache server

9. The Installation Cookbook (this document)

The DIS installation kit is available at:

http://sec.cs.kent.ac.uk/permis/downloads/Level3/DIS.shtml

Download the DIS installation kit, unzip serverSide.zip to a directory in the DIS server computer, say </home/serverSide>; and unzip clientSide.zip to a directory in the DIS client computer, say </home/clientSide>, then you'll see the items listed above.

II. Installation steps for the DIS web service server on the DIS

server computer

Step 1. Make sure that the Tomcat Application server is installed and working correctly.

1. Please refer to the Tomcat manual at http://jakarta.apache.org/tomcat/ . Assume that you have installed Tomcat on the directory $TOMCAT on your computer.

2. Start the Tomcat by the command: “$TOMCAT/bin/startup.sh”. We assume the default ports for Tomcat is 8080 (without ssl) and 8443 (with ssl). Open your webbrowser and go to the http://localhost:8080 URL. You should see the welcome page of the Tomcat. If not, refer to the Tomcat manual and check the firewall on your computer system.

3. Copy three files from the directory </home/serverSide/serverSideKeystore> into the directory <$TOMCAT/conf>: truststore.jks, cacert.cer, dis-cert.p12.

4. Open the Tomcat configuration file <$TOMCAT/conf/server.xml> in an editor. Locate the configuration section for SSL connection, uncomment it and edit it as follows.



<Connector className="org.apache.coyote.tomcat5.CoyoteConnector"

port="8443" minProcessors="5" maxProcessors="75"

enableLookups="true"

acceptCount="10" debug="5" scheme="https" secure="true"

useURIValidationHack="false" disableUploadTimeout="true">

<Factory className="org.apache.coyote.tomcat4.CoyoteServerSocketFactory"

clientAuth="false" protocol="TLS"

keystoreFile="$TOMCAT/conf/dis-cert.p12"

keystorePass="dis123" keystoreType=”PKCS12”/>

</Connector>

Two changes are needed for this configuration file.(1) Change the attribute "keystoreFile" to the path and file name of the Java keystore file <tomcat.keystore> which is copied to your computer.

(2) Change the attribute "keystorePass" to “dis123”, which is the default password for the Java keystore <tomcat.keystore>.

http://localhost:8080/

http://jakarta.apache.org/tomcat/

Restart your Tomcat server by two commands “$TOMCAT/bin/shutdown.sh” and “$TOMCAT/bin/startup.sh”. Open your webbrowser and go to “https://localhost:8443”. Verify the certificate presented by Tomcat and make sure that it is not expired and accept it. You should also see the welcome page of Tomcat. If not, check your configuration file (the above part for SSL connection) and check the firewall on your computer system.

5. Change the “clientAuth” directive from “clientAuth=”false” to “clientAuth=true”. Restart the Tomcat. This will tell Tomcat to require mutual authentication between Tomcat and its clients. Open your webbrowser and go to “https://localhost:8443”. Accept Tomcat’s certificate and the connection should FAIL because your webbrowser does not have any trusted certificate. Now you can import the soa-cert.p12 key file (in /home/serverSide/serverSideKeystore directory) to your webbrowser (in Mozilla-Firefox, you go to Tools ->Options->Advanced->Security tab, View certificates and click the Import button). The password for the p12 key is “l3tM3InNow”. Now you can go to “https://localhost:8443”, accept Tomcat’s certificate and the connection should FAIL again. This is because the issuer of your certificate is not trusted by Tomcat. There are three ways to make the issuer of your certificate be trusted by Tomcat. The first method is adding the issuer’s certificate (in our example, it is the cacert.cer file) to the default truststore of Tomcat, which is the $JAVA_HOME/jre/lib/security/cacerts file ($JAVA_HOME is the directory in which you have installed the JRE). You can use the following command for importing the cacert.cer file to the default truststore (the password for this truststore is “changeit”).

keytool -import -alias rootca -keystore $JAVA_HOME/jre/lib/security/cacerts -trustcacerts –file $TOMCAT/conf/cacert.cer

The second method is that you modify the $TOMCAT/bin/catalina.sh file so that Tomcat uses the new truststore. You can do that by adding the following lines to the catalina.sh file before the “echo "Using CATALINA_BASE: $CATALINA_BASE" “ line:

JAVA_OPTS="$JAVA_OPTS -Djavax.net.ssl.trustStore=TRUSTSTORE -Djavax.net.ssl.trustStorePassword=PASSWORD"

JAVA_OPTS="$JAVA_OPTS -Xms386M -Xmx768M"

JAVA_OPTS="$JAVA_OPTS -server"

For testing purposes, you can use the “$TOMCAT/conf/truststore.jks” for the TRUSTSTORE (because the cacert.cer certificate is already imported in this keystore) and “dis123” for the PASSWORD.

If you use version 5.0 of Tomcat, you have a third method for specifying the truststore and the password (see http://tomcat.apache.org/tomcat-5.0-doc/ssl-howto.html).

For example,

<Connector port="9443" className="org.apache.coyote.tomcat5.CoyoteConnector" acceptCount="10" bufferSize="2048"

clientAuth="true" compression="off" connectionLinger="-1" connectionTimeout="60000"

connectionUploadTimeout="300000" debug="0"

disableUploadTimeout="false" enableLookups="true" keepAlive="true" maxHttpHeaderSize="8192"

http://tomcat.apache.org/tomcat-5.0-doc/ssl-howto.html

https://localhost:8443/



keystoreFile="$TOMCAT/conf/dis-cert.p12" keystorePass="dis1231" keystoreType="PKCS12"

truststoreFile="$TOMCAT/conf/truststore.jks" truststorePass="dis123" truststoreType="JKS"

maxKeepAliveRequests="100" maxProcessors="20" minProcessors="5" protocol="HTTP/1.1"

protocolHandlerClassName="org.apache.coyote.http11.Http11Protocol" proxyPort="0" redirectPort="-1"

scheme="https" secure="true" serverSocketTimeout="0" sslProtocol="TLS" tcpNoDelay="true"

tomcatAuthentication="true" xpoweredBy="false">

<Factory className="org.apache.coyote.tomcat5.CoyoteServerSocketFactory" clientAuth="true"

keystoreFile="$TOMCAT/conf/dis-cert.p12" keystorePass="dis123" keystoreType="PKCS12"

truststoreFile="$TOMCAT/conf/truststore.jks" truststorePass ="dis123" truststoreType="JKS"

protocol="TLS" />

</Connector>

Now you can restart Tomcat and go to “https://localhost:8443”, accept Tomcat’s certificate and you should be able to see the default Tomcat welcome page. If you do not see that page then you need to double check Tomcat’s configuration file, the paths of the keys, certificates and keystores.

Step 2. Install the Apache Axis SOAP server on the Tomcat server

1. Download a package of Apache Axis from http://ws.apache.org/axis/, version 1.4, unwrap the package into a new directory, say </home/serverSide/axis>;

2. Copy the directory </home/serverSide/axis/webapps/axis> along with all its contents into the <$TOMCAT/webapps>. You will get a new directory in Tomcat: <$TOMCAT/webapps/axis>. Restart Tomcat.

3. Navigate to the start page of the webapp, https://localhost:8443/axis/. You should now see an Apache-Axis start page. If you do not, then check the above two steps.

4. Set the paths for the Axis. You should edit the /etc/profile and add the following lines:

AXIS_HOME=/home/serverSide/axis

AXIS_LIB=$AXIS_HOME/lib

AXISCLASSPATH=$AXIS_LIB/axis.jar:$AXIS_LIB/axis-ant.jar: $AXIS_LIB/commons-discovery-0.2.jar:$AXIS_LIB/commons-logging-1.0.4.jar:$AXIS_LIB/jaxrpc.jar:$AXIS_LIB/saaj.jar:$AXIS_LIB/log4j-1.2.8.jar:$AXIS_LIB/wsdl4j-1.5.1.jar

export AXIS_HOME AXIS_LIB AXISCLASSPATH

5. Logout from your system and then login to your system again. The new environment will have the above setting environment variables.

5. Validate the Axis server with happyaxis. Navigate your webbrowser to “https://localhost:8443/axis/happyaxis.jsp”. This will bring you to happyaxis.jsp a test page that verifies that needed and optional libraries are present. If any of the needed

https://localhost:8443/axis/happyaxis.jsp

https://localhost:8443/axis/

http://ws.apache.org/axis/


libraries are missing, Axis will not work. You must not proceed until all needed libraries can be found, and this validation page is happy. If Axis does not work, you should refer to the Axis installation instructions in your axis installation directory </home/serverSide/axis/docs>.

Note that our instructions here only apply for version 1.4 of Axis. If you use a different version of it then you need to refer to its own instructions. You should read and follow the installation instruction for the Axis on its homepage if you experience any problem.

Step 3. Install the DIS service on the Axis server

1. Edit the DIS configuration file dis.cfg

The default file /home/serverSide/discfg/dis.cfg will contain the following contents:

PolicyIssuer cn=SOA,ou=admin,o=permis, c=gb ---------- In case you use an XML policy file, you do not need to use this parameter.

PolicyIdentifier 1.2.826.0.1.3344810.6.0.0.n ----------- In case you use an XML policy file, you do not need to use this parameter.

PolicyLocation ldap://localhost -----------for holding the policy. This parameter specifies the URL of the LDAP server that stores the policy certificate. You can use “file://path_to_policy_file” for a policy stored in a file. Two types of file-stored policy are supported: X.509 AC policy (suffix “ace”) and XML policy file (suffix “xml”).

PolicyLocationUsername cn=aa1,ou=staff,o=permis,c=gb --------------- specifies the username for read access to the LDAP that stores the policy certificate. In case you use a file-stored policy, you do not need this parameter.

PolicyLocationPW aa1 -----------------specifies the password for LDAP authentication of the username above. In case you use a file-stored policy, you do not need this parameter.

RootPKC $TOMCAT/conf/cacert.cer

CredentialLocation ldap://localhost ----------- for holding the role attribute certificates of users. This parameter specifies the URL of the LDAP server that stores the delegated role attribute certificates

CredentialLocationUsername cn=root,c=gb ------ specifies the username of the manager who has write access to all the LDAP user entries

CredentialLocationPW secret ---- specifies the password for the above username

downgradeable 1

SigningKeyFile $TOMCAT/conf /dis-cert.p12 --- the location of the DIS’s private key used for signing the delegated role attribute certificates

SigningKeyPW dis123 --- password for the above

LDAP_AC_Attribute attributeCertificateAttribute

ldap://localhost

LDAP_PKC_Attribute userCertificate

DebugLevel info----------------------this parameter tells the DIS to print out debug information. There are five debugging levels: debug, info, warn, error and fatal.

LogFile dis.out-------- parameter tells the name of a file that the DIS will print out the logging information. It will be put in logs directory in $TOMCAT.

TrustedProxy cn=httpd, ou=admin,o=permis, c=gb ---- change this to the subject DN in the SSL certificate of the Apache server that is acting as your DIS client computer,

SearchRequestor anyone------ SearchRequestor has two values: “anyone” and “revokers”. If it is set to “anyone” then any one can search and view people ACs. If it is set to “revokers” then user only the ACs that user can revoke will be present to user.

Please note that:

(1) The policy ID (PolicyIdentifier) is 1.2.826.0.1.3344810.6.0.0.n, where n can be anything you want. In this demonstration package, n is 1.

If you do not have access to your own object identifier branch, then you can request us to issue you one under our branch 1.2.826.0.1.3344810.6. Alternatively you can now use any URN as the policy object ID.

(2) We assume the root CA certificate file cacert.cer and the DIS pkcs#12 file dis-cert.p12 have been copied to the directory <$TOMCAT/conf >. If it is not the case in your system, then please change them according to your system situation.

(3) When the parameter downgradeable is 1, it means true, privileges can be further constrained and downgraded by the DIS if the privilege delegation requested by the user is greater than that allowed by your delegation policy. 0 means false, the privilege delegation requested by the user must be allowed by your delegation policy or the user’s request will be rejected.

(4) The parameter TrustedProxy specifies the subject name in the public key certificate of a trusted DIS client. It can be repeated as many times as needed, to allow for several different trusted proxies. Only when a DIS client is trusted, can it work as a proxy to request privilege delegation on behalf of other users.

2. Copy the DIS configuration files dis.cfg and serialnumber.cfg to Tomcat

(1) Create a new directory path in Tomcat: <$TOMCAT/webapps/axis/WEB-INF/classes/issrg/dis>.

(2) Then copy the two files dis.cfg and serialnumber.cfg in the DIS installation directory </home/serverSide/discfg> to <$TOMCAT/webapps/axis/WEB-INF/classes/issrg/dis>.

3. Copy the DIS libraries to Tomcat

Copy all the DIS library files in </home/serverSide/dislib> into the directory <$TOMCAT/webapps/axis/WEB-INF/lib>.

4. Deploy the DIS Web Service on Tomcat and Axis

1. Restart Tomcat.

2. In the DIS installation directory </home/serverSide> where the file disDeploy.wsdd is located, run the following command:

java -cp $AXISCLASSPATH org.apache.axis.client.AdminClient disDeploy.wsdd

3. Now restart Tomcat to activate the DIS web service server

5. Validate that the DIS service is installed on Axis

Navigate your webbrowser to “http://localhost:8080/axis/services/DIS” and “https://localhost:8443/axis/services/DIS”. You should see the welcome message showing that the DIS is a service on Axis. If it is not, check the step 3 and step 4 above.

Step 4. Load the LDAP contents

We assume you are using OpenLDAP 2.2.x.

1. Replace your OpenLDAP schema file core.schema with the schema file core.schema provided in the directory <home/serverSide/disschema>. Please read OpenLDAP documentation for further details.

2. Change to the directory </home/serverSide/>. Use your OpenLDAP administration tool to load our demonstration LDAP contents into your newly configured OpenLDAP, by running the following command:

ldapadd -f data.ldif -xv -D "cn=root,c=gb" -W

If the command produces some errors then you can edit the data.ldif file by an editor. Navigate to the places that start with the attributeCertificateAttribute and the userCertificate strings. You may needs to add or delete “;binary” after these strings and you need to refer to your LDAP server documents to find out what strings are used for the attributeCertificateAttribute and the userCertificate attributes. Note that these strings are the same as the strings in the dis.cfg file in term of “;binary” suffix.

III. Installation steps for the DIS Apache client on the DIS

client computer

Our sample DIS client is written in the PHP script language and runs on the Apache web server. The Apache web server uses mod_auth_ldap for authenticating users. This DIS client is only for demonstration purposes, you can develop your own DIS client after you are familiar with the DIS.

https://localhost:8443/axis/services/DIS

http://localhost:8080/axis/services/DIS

Step 1. Configure and install the Apache web server

With Apache 2.0, you should refer to the official installation documentation in the Apache website. For using the DIS, you need to enable some modules when configuring the Apache: --enable-auth-ldap, --enable-proxy, --enable-proxy-http, --enable-so, --enable-ssl, --enable-unique-id, --enable-mods-shared(=all).

You may have problem with supporting authentication using LDAP when building the Apache. One method to overcome this issue is to compile the Apache without the mod_auth_ldap support and after you have the Apache webserver working on your machine, download the mod_auth_ldap from http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html and compile the module.

For Windows users, you may need to download an Apache package with a Windows installer (http://httpd.apache.org/download.cgi). The Windows installer must include openSSL (e.g. apache_2.2.9-win32-x86-openssl-0.9.8h-r2.msi from the above link is such an installation file) since this testing client needs a SSL connection.

We assume that your Apache is installed at the location <$APACHE>. Now you can start Apache to make sure that it works by the command:

$APACHE/bin/apachectl start

Navigate your webbrowser to “http://localhost”. You should see the Apache default welcome page. If it is not then you need to check the above installation steps and the firewall on your computer system.

Step 2. Configure and install PHP

You can download PHP version 4 or 5 (version 5 is recommended) for the Apache server from the PHP homepage at http://www.php.net/downloads.php.

When you run the configure script when installing PHP, follow the PHP installation in-struction and you need to use some options:

- Enable SOAP messages: --enable-soap

- Build shared Apache 2.0 module: --with-apxs2=$APACHE/bin/apxs

- Enable SSL: --with-openssl

- Enable LDAP: --with-ldap

For Windows users, you can easily install PHP with a PHP Windows installer. You may need to download a Windows PHP zip file, which includes various modules (.dll) you need. You can enable the needed modules by copying them into $PHP/ext.

After running the configure script, you can run "make" and "make install" as normal. Af-ter installing PHP, you need to tell the Apache server that it can handle PHP files by adding the following line into the Apache configuration file (httpd.conf):

AddType application/x-httpd-php .php .phtml

http://www.php.net/downloads.php

http://localhost/

http://www.muquit.com/muquit/software/mod_auth_ldap/mod_auth_ldap.html

You can test Apache and PHP by creating a file called info.php for example in the $APACHE/htdocs directory. The content of the info.php is “<?php phpinfo(); ?>. Restart your Apache by the following commands:

$APACHE/bin/apachectl stop

$APACHE/bin/apachectl start

Navigate your webbrowser to the http://localhost/info.php URL. You should see information about the installed PHP. Make sure that it supports SOAP, LDAP and SSL. If it is not, check the PHP installation step above.

Step 3. Copy the DIS files into the Apache directory

(1) Copy /home/clientSide/clientSideKeystore/httpd-cert.pem into <$APACHE/conf/ssl.crt/>.

(2) Copy /home/clientSide/clientSideKeystore/httpd-key.pem into <$APACHE/conf/ssl.key/>.

(3) Copy /home/clientSide/clientSideKeystore/cacert.pem into <$APACHE/conf/ssl.crt/>

(4) Copy /home/clientSide/clientSideKeystore/httpd-cert-key.pem into <$APACHE/conf/ssl.crt/>.

(5) Create a new directory in Apache: <$APACHE/htdocs/dis>.

(6) Copy the following 3 files into <$APACHE/htdocs/dis>.

/home/clientSide/clientSidePHP/dis.php

/home/clientSide/clientSidePHP/rs1.php

/home/clientSide/clientSidePHP/proxysigning.cfg

(7) Copy the following 3 files into <$APACHE/htdocs>.

/home/clientSide/clientSidePHP/dis.html

/home/clientSide/clientSidePHP/policy.html

/home/clientSide/clientSidePHP/username.html

(8) Copy the directory </home/clientSide/clientSidePHP/images> along with its contents into <$APACHE/htdocs/dis>. Move the Role.gif file from this directory to <$APACHE/htdocs>. Now you will have got a new directory <$APACHE/htdocs/dis/images> along with 4 image files in it.

Step 4. Edit the Apache configuration file for SSL

Locate the following section in the Apache configuration file $APACHE/conf/ssl.conf: ($APACHE/conf/extra/httpd-ssl.conf for the Apoache 2.2 and later)

ProxyRequests Off

<Proxy *>

http://localhost/info.php

Order allow,deny

Allow from all

</Proxy>

If this section does not exist then you need to add it to the bottom of the file. Just after this section, add the follows contents:

ProxyPass /disproxy https://Your.DIS.Server.Domain.Name:8443/axis/services/DIS

SSLProxyEngine on

SSLCertificateFile $APACHE/conf/ssl.crt/httpd-cert.pem

SSLCertificateKeyFile $APACHE/conf/ssl.key/httpd-key.pem

SSLCACertificateFile $APACHE/conf/ssl.crt/cacert.pem

(**) – This is a bookmark referred to later in Step 7.

and comment out other directives about SSLCertificateFile, SSLCertificateKeyFile and SSLCACertificateFile in the ssl.conf (or extra/httpd-ssl.conf) file.

In the above configuration you need to change the string “Your.DIS.Server.Domain.Name” in the directive “ProxyPass” to your DIS server’s Internet Domain Name. You also need to change <$APACHE> to your local Apache home directory. For Apache 2.2, you need to add the mod_proxy_http to your http.conf file along with the mod_proxy and mod_proxy_html modules.

Now you can restart Apache with ssl support by the following commands:

$APACHE/bin/apachectl stop

$APACHE/bin/apachectl startssl

Navigate the webbrowser to “https://localhost”. You should see the Apache certificate. Accept it and you will see the Apache default welcome page. If it is not then you should check the step above.

Step 5. Edit the Apache configuration file

In the Apache configuration file $APACHE/conf/ssl.conf (or extra/httpd-ssl.conf), add a new section at the end of this file as follows:

<Directory $APACHE/htdocs/dis> ---- You need to change this to your local directory. DO NOT USE SYMBOLIC LINK!

AuthName "Delegation Issuing Service"

AuthType Basic

https://localhost/

AuthLDAPURL ldap:// Your.LDAP.Server.Domain.Name /c=gb?uid --- You may need to change the uid according to your mod_auth_ldap configurations

require valid-user

AllowOverride FileInfo AuthConfig Limit

Options MultiViews Indexes SymLinksIfOwnerMatch IncludesNoExec

<Limit GET POST OPTIONS>

Order allow,deny

Allow from all

</Limit>

</Directory>

In the above configuration, the LDAP server can be either on the local computer or on the remote one, has a root DN "c=gb", and the attribute used for authenticating users is the uid attribute. You may need to replace the line “AuthLDAPURL ldap:// Your.LDAP.Server.Domain.Name /c=gb?uid” with the following 4 lines (depends on your mod_auth_ldap module):

LDAP_Server Your.LDAP.Server.Domain.Name

LDAP_Port Your-LDAP-Port

Base_DN “c=gb”

UID_Attr uid

For Apache 2.2, you need to add “AuthBasicProvider ldap” and “AuthzLDAPAuthoritative off” inside the <Directory $APACHE/htdocs/dis> section.

In the dis.php and rs1.php files, there is a line with

$authenticateUID = $_SERVER[“LDAP_USER”]

You may also need to replace $_SERVER[“LDAP_USER”] with $_SERVER[“AUTHENTICATE_UID”]. This change also depends on your mod_auth_ldap module.

Step 6. Configure the DIS Apache client

The DIS Apache client configuration file $APACHE/htdocs/dis/proxysigning.cfg contains the following contents:

ldapserver Your.LDAP.Server.Domain.Name

search c=gb --- Your LDAP root DN

ServiceLocation https://Your.APACHE.Server.Domain.Name/disproxy ---- point to the address of the DIS service proxy in the Apache server.

role Student --- the roles displayed on the user interface in the browser

role Staff

role Professor

role Researcher

role Admin

type permisRole --- indicate the attribute type of the above roles

key uid ---- the search field in the LDAP

Step 7. Restart Apache and test the DIS

Restart Apache in SSL mode. Open your webbrowser, type in the URL of the DIS Apache client computer (e.g. https://localhost/dis.html if the browser is on the same computer as Apache). You will see the DIS welcome web page, which will be described in detail in Section IV. Click on the “Enter the Demonstration page” link. Login as soa (the password is soa) and try to issue an Attribute Certificate to the entry with the aa1 uid. It will FAIL because Tomcat requires client authentication and your Apache web server does not have any certificate and private key for establishing a secure connection to the Tomcat server.

Add the following directives in the ssl.conf file right after the (**) bookmark in Step 4:

SSLProxyCACertificateFile $APACHE/conf/ssl.crt/cacert.pem

SSLProxyMachineCertificateFile $APACHE/conf/ssl.crt/httpd-cert-key.pem

<Directory $APACHE/htdocs/disproxy>

Order allow,deny

Allow from Your.DIS.Server.Domain.Name

</Directory>

You need to change <$APACHE> to your local Apache home directory. Restart Apache in SSL mode and try to issue an AC to the entry with aa1 uid again. It should work. If it does not then double check the above directives and the paths that you store the certificates and keys.

After successfully performing the DIS Acceptance tests in Section V, you can later modify and change the DIS configurations and even the DIS software itself according to your own needs.

https://localhost/dis.html

IV. The DIS end user guide

1. Java Client

The Java client is shipped within dis.jar. It is called by typing the following command line, for example:

java -cp log4j-1.2.8.jar:axis.jar:dis.jar:jaxrpc.jar:commons-logging-1.0.4.jar:commons-discovery-0.2.jar issrg.dis.TestDIS <test-file>

For Windows users:

java -cp log4j-1.2.8.jar;axis.jar;dis.jar;jaxrpc.jar;commons-logging-1.0.4.jar;commons-discovery-0.2.jar issrg.dis.TestDIS <test-file>

where <test-file> indicates a file which tells the testing parameters. Users can find log4j-x.jar, axis.jar jaxrpc.jar, commons-logging-x.jar and commons-discovery-x.jar from the Axis installation.

A test file should consist of those parameters in the format of, for example

issuerDN=cn=SOA,ou=admin,o=PERMISv5,c=GBholderDN=cn=AA1,ou=staff,o=PERMISv5,c=GBroleValues=Admin,ProfessorroleType=permisRolefrom=2008.1.1 00:00:00to=2018.1.1 00:00:00assertion=candeep=1url=https://129.12.16.178:8443/axis/services/DISlog=/home/pip/permis.logkeyStore=/sslcert/httpd-cert.p12keyStorePassword=dis123keyStoreType=PKCS12trustStore=/sslcert/truststore.jkstrustStorePassword=dis123trustStoreType=JKS

The meaning of those parameters of issuerDN, holderDN, roleValue, roleType, from, to, assertion, deep and url is the same as defined in the DIS Apache client. The key store parameters define a client certificate and the trust store parameters specify the trusted CA certificates. Users can find some test certificates from this release.

2. Apache Client

At Kent University, we provide a demonstration DIS service at the Internet address http://issrg-beta.cs.kent.ac.uk:8080/dis.html. After visiting this web address from your Internet browser, you will see the following welcome web page.

http://issrg-beta.cs.kent.ac.uk:8080/dis.html

To know more about the issuing policy and the username/password used in this demonstration, you can click the relevant links on this page. The policy used in this demonstration is described in Annex A.

Now click on the link “Enter Demonstration page”, you will be asked to type in your username and password. You can use soa/soa as your username/password for this demonstration. After you login as an SOA, you will see the following delegation issuing interface.

Suppose you are going to issue the role “student” and “staff” to a user “student1” in the organization PERMIS, then you can type in “student1” in the field <add your search string here> in the “Search LDAP Server” area, and click the button “search”. Then the following search results will be displayed.

Select the item “cn=student1,ou=student,o=PERMIS,c=GB”, click the button “Choose”, and the following interface will be displayed.

Since you are trying to issue a role “student” and a role “staff” to the user “cn=student1,ou=student,o=PERMIS,c=GB”, in the area of “Select the roles you want to assign to the Holder”, you can select the item “student” in the field “Available roles” and then click the button “Add Role”, then again select the item “staff” in the field “Available roles” and then click the button “Add Role”.

Suppose you wish the roles to be valid from 1 Sept 2005 to 1 July 2007, then you can do this by selecting the correct dates in the field “From” and “To” in the area “Validity Period”. Now the user interface displays as follows.

Suppose you want to make the holder (student1) be able to delegate these roles to someone else, then you can click the button “Yes” by the side of the question: “Can the Holder delegate this(these) role(s) to someone else?”. Now you reach the following web page.

On this web page, you are given two options to allow or forbid the holder (student1) to execute these roles. Select the appropriate one as you wish. Suppose you select the “Allow” button.

Now you need to input the depth of the hierarchy that the holder can delegate these roles to his subordinate(s). Suppose you input “5” in the appropriate field. Click the button “Update Illustration”, you can see the following web page.

Now you can click the button “Issue AC”. The following results will display in the following web page.

The results on this web page show that although you as an SOA were trying to issue the “student” and “staff” roles to the user “student1”, only one role “student” is approved and the validity period that you applied for is constrained by the DIS according to your (soa) own privileges.

Now you can try some other users and privilege combinations at this DIS web site as you wish.

V. Acceptance Tests

The result of the testing process is totally dependent on your delegation policy stored in the policy certificate, the DIS's role attribute certificate, the requests from users to the DIS, the sequence of the requests and the role attribute certificates stored in the user entries in the LDAP (so you should ensure that the testing entries do not contain any role ACs before the acceptance testing process starts).

In the following acceptance tests, you should use our example delegation policy (in Annex A) and your LDAP directory should have our LDAP directory configuration (shown in Step 1 below). Instead of showing you the Apache client screenshots, we present the parameters of each SOAP request and reply from the DIS. You will need to prepare your requests according to the requests' parameters and compare the results' parameters with the results' parameters replied from the DIS.

Step 0: Make sure that AC attributes can be stored in your LDAP server

If your LDAP schema has not been configured for storing AC attribute then you need to modify the LDAP schema for storing AC attributes. It has been done when you replace the core.schema file. If you haven’t done it then you need to follow this step.

Modifying the LDAP Schema for Storing AC Attributes

We assume you already have a standard LDAP directory installed and configured. You need to add the ‘attributeCertificateAttribute’ attribute type and the ‘pmiUser’ object class to your LDAP schema (core.schema file in OpenLDAP). Your core schema may be installed on your harddisk when you installed your LDAP server and it may be in your LDAP folder.

The ‘attributeCertificateAttribute’ attribute type definition needs the following:

1. Name: attributeCertificateAttribute

2. OID (object identifier): 2.5.4.58

3. Syntax: Binary

The LDAP standard defines the 'attributeCertificateAttribute’ attribute type as shown below:

attributetype (2.5.4.58 NAME 'attributeCertificateAttribute'DESC 'A binary attribute certificate'EQUALITY octetStringMatchSYNTAX 1.3.6.1.4.1.1466.115.121.1.5)

IMPORTANT NOTE. Some LDAP servers may require

SYNTAX 1.3.6.1.4.1.1466.115.121.1.8

in the above definition.

After creating the attribute type ‘attributeCertificateAttribute’ we are now ready to create the object class pmiUser. The pmiUser object class needs the following:

1. Name: pmiUser

2. OID (object identifier): 2.5.6.24

3. Parent: top

4. Required Attributes: - (NONE)

5. Optional Attributes: attributeCertificateAttribute

The X.509 standard defines the 'pmiUser' object class as shown below:

objectclass (2.5.6.24 NAME 'pmiUser'SUP topDESC 'A pmi entity that can contain X509 ACs'MAY (attributeCertificateAttribute $ cn))

Note that you can only store AC attributes in an entry if this entry contains the pmiUser objectClass so you need to make sure that the entries that you want to store ACs in have the pmiUser objectClass.

You may need to re-start your LDAP server to activate this new schema.

Step 1: Prepare the test entries in the LDAP

First of all, you should remove all the entries stated in the group 1, group 2 and group 3 (see below). This removal makes sure that your testing entries are clean. Now you need to import the test.ldif file to your LDAP directory. You may have done this from step 1 in “Installation steps for the DIS web service server on the DIS server computer” section.

(In OpenLDAP you can do this by using the following command:

ldapadd -f data.ldif -xv -D "cn=root,c=gb" -W

You should change the “cn=root,c=gb” to the root user's DN of your OpenLDAP.)

Three groups of entries will be installed in your LDAP directory as follows:

Group 1: the entries in the admin group.

cn=soa,ou=admin,o=permis,c=gb

cn=dis,ou=admin,o=permis,c=gb

cn=admin1,ou=admin,o=permis,c=gb

Group 2: the entries in the staff group.

cn=aa1,ou=staff,o=permis,c=gb





Group 3: the entries in the student group.

cn=student1,ou=student,o=permis,c=gb





Each entry has the following attributes (some entries may have some more attributes): userPassword, uid, sn and cn. We use one simple rule for the value of these attributes: they are exactly the same as the value of the cn field in user's DN. For example, the entry “cn=aa1,ou=staff,o=permis,c=gb” has userPassword=aa1, uid=aa1, sn=aa1 and cn=aa1.

The Public Key Certificates for the two entries cn=SOA, ou=admin, o=permis, c=gb and cn=dis, ou=admin, o=permis, c=gb are stored in the test.ldif file so you do not need to consider about them. The delegation policy AC of the cn=SOA, ou=admin, o=permis, c=gb is also stored in the test.ldif file.

Step 2: Understanding the request's parameters to the DIS and the reply's parameters from the DIS

2.a Request

Look at the example SOAP request below.

Requester: cn=soa,ou=admin,o=permis,c=gb

Holder: cn=admin1,ou=admin,o=permis,c=gb

RoleType: permisRole RoleValues: Admin, Professor

From: 2003.01.01 To: 2011.01.01

Assertion: cannot

Depth: 0

The request parameters are as follows:

1. “Requester” is the user that requests the DIS to issue ACs. When you try to access to the DIS via an Apache webpage, you have to provide your username (in our test cases it is the uid value of the requester's entry in the LDAP) and your password for LDAP authentication. When you want to change the requester you have to totally close your web-browser and try to access the DIS webpage again using a different username.

2. “Holder” is the person (or entry) that the requester wants to delegate an AC to. You should type (part of) the holder's cn in the search textbox and press the “Search” button. The results will appear in the drop-down listbox on the right hand side. You choose the holder's DN from this drop-down listbox and click the “Choose” button.

3. “RoleType” is the type of the attributes. The value of this variable is pre-configured in the policysigning.cfg file. When necessary, you can change the value of this variable by editing the policysigning.cfg file (in $APACHE/htdocs/dis directory).

4. “RoleValues” are the values of the attributes. There are five possible values for the “RoleValues” in our test cases: Admin, Professor, Researcher, Staff and Student. Using the “Available roles” drop-down listbox in the webpage, you can select the value(s) and add to the “Assigned roles” drop-down listbox. When necessary, you can change the set of values for the “RoleValues” variable by editing the proxysigning.cfg file.

5. “From” and “To” form the validity time of the requested AC. You can choose values for these variables by using the “From” and “To” drop-down listbox in the

webpage.

6. “Assertion” receives one value in the set of two values: {can, cannot}. When you click on the “ALLOW the Holder to execute these roles” radio button, the assertion value is “can” and when you click on the “FORBID the Holder to execute these roles” radio button then the assertion value is “cannot”.

7. “Depth” is the delegation depth for the requested AC. When you select the “Yes” button (that is next to the “Can the Holder delegate this/these role(s)”) the value of the “Depth” is set to 1 by default. This is the value in the “How deep in the hierarchy can the Holder delegate this/these role(s)” textbox.

2.b Reply's parameters from the DIS

Look at the “Reply” below.

Reply:

Done|CN=admin1,OU=admin,O=permis,C=gb|permisRole:Admin| Jan 01 2004| Jan 01 2010|Holder can not assert privileges|0

The “Reply” parameters are as follows:

“Done” means the requested AC has been issued. “CN=admin1,OU=admin,O=permis,C=gb” is the holder's DN.

“permisRole:Admin” is the attribute value (or list of attribute values) of the attribute in the issued AC.

“Jan 01 2004| Jan 01 2010” is the validity time (from and to) of the issued AC.

“Holder can not assert privileges” is the expression of the “cannot” value of the “Assertion” variable.

“0” means the delegation depth is unlimited (value -1 means “No delegation”, value 0 means “unlimited delegation”, value 1 means “one step delegation” etc.)

Actually, both the request and reply messages also contain hh:mm:ss for time instances (for example, the “From” time instance may have the value “2004:01:01 00:00:00”) but they are not displayed on the webpage. For the requests to the DIS from the webpage, the times are always set to 00:00:00 GMT, and the replies from the DIS are set likewise, unless they are constrained by the Delegation Policy.

Step 3: Test cases

Now you can proceed with the test cases. DO NOT CHANGE THE SEQUENCE OF THE TEST CASES AND THE PARAMETERS OF THE REQUESTS. OTHERWISE, YOU MAY NEED TO RESTART THE TESTING PROCESS FROM BEGINNING. Some former test cases are the preparation for some later test cases.

The following diagram shows the sequence of delegations that are attempted in the following tests.

Test number: 1

Description: to confirm that the DIS cannot be used to delegate any privilege ACs until it has been directly given a privilege AC by the SOA



RoleType: permisRole RoleValues: Admin,

From: 2004.01.01 To: 2010.01.01

Assertion: cannot

Depth: 0

Reply:

Delegation Issuing Service does not have enough privilege to issue this certificate

Preparation for all the following test cases. Directly issue an AC to the DIS and store it in your LDAP server.

You can use the ACM (it can be downloaded from http://sec.cs.kent.ac.uk/permis/downloads/Level1/acm.shtml) for issuing an AC for the DIS.

1. Run the ACM.

2. Enter the Edit menu and choose “Preferences”.

3. In the LDAP URL textbox, type your LDAP's URL and in the AC LDAP Type textbox, type your LDAP's AC type. Note that you need to have write permission for storing ACs to the LDAP server and a correct AC LDAP type (attributeCertificateAttribute or attributeCertificateAttribute;binary), which is dependent on the LDAP server that you use.

4. Click “Test Connection” to make sure that you have a connection to your LDAP server.

5. Choose the signing key as the soa-cert.p12 provided in the test package.

6. Click the “Accept” button.

7. Enter the Certificate menu and choose “Edit existing...”.

8. In the Select media window, choose “Disk” and load the DISAC.ace provided in the test package and click the “OK” button.

9. Click the “Generate and Save” button.

10. Enter the password for the PKCS#12 signing key (the password is “l3tM3InNow”) and click the “OK” button.

11. Select your LDAP directory (Select media: LDAP Directory) for storing the AC.

12. Type a pair of username/password in the “Login” and the “Password” textboxes and click the “Save” button.

Now you need to restart your Tomcat server for updating the DIS with the new issued AC.

Test number: 2

http://sec.cs.kent.ac.uk/permis/downloads/Level1/acm.shtml

Description: to confirm that the DIS cannot delegate any additional privilege ACs to itself, even if the requester has the necessary privileges.


Holder: cn=dis,ou=admin,o=permis,c=gb

RoleType: permisRole RoleValues: Admin

From: 2004.01.01 To: 2010.01.01

Assertion: cannot

Depth: 0

Reply:

Delegation Issuing Service does not have enough privilege to issue this certificate

=============================================================

Test number: 3

Description: to confirm that a delegator can delegate multiple roles in an AC, but the DIS will condense these to the highest role in the role hierarchy (if possible). The “Assertion” variable is “can” and delegation depth is unlimited. In this example, the From date has been constrained to comply with the Delegation Policy.




From: 2003.01.01 To: 2011.01.01

Assertion: can

Depth: 0

Reply:

Done|CN=admin1,OU=admin,O=permis,C=gb|permisRole:Admin| Jan 01 2004| Jan 01 2010|Holder can assert privileges|0

Test number: 4

Description: to confirm that a delegator can issue multiple roles in an AC, and in this case the DIS is unable to condense them. The “Assertion” variable is “can” and delegation

depth is 2. Note that the validity date had been altered to conform to the delegation policy.


Holder: cn=aa1,ou=staff,o=permis,c=gb

RoleType: permisRole RoleValues: Professor, Researcher

From: 2001.01.01 To: 2006.01.01

Assertion: can

Depth: 2

Reply:

Done|CN=aa1,OU=staff,O=permis,C=gb|permisRole:Professor, Researcher| Jun 01 2004| Jan 01 2006|Holder can assert privileges|2

Test number: 5

Description: to confirm that the DIS cannot issue any ACs with an unknown attribute type or attribute value.

To do this test, you need to change the value of RoleType in the proxysigning.cfg file (from permisRole to perRole).



RoleType: perRole RoleValues: Staff

From: 2005.01.01 To: 2007.01.01

Assertion: can

Depth: 2

Reply:

Role type or role value is not supported in policy

Test number: 6

Description: to confirm that a delegator cannot issue any AC to an entry that is not in any

subject domain.

You need to change the value of the RoleType variable in the proxysigning.cfg file back to permisRole.


Holder: cn=external, o=permis,c=gb

RoleType: permisRole RoleValues: Staff

From: 2005.01.01 To: 2006.01.01

Assertion: can

Depth: 2

Reply:

Issuer does not have enough privilege or can not downgrade privilege or wrong request

Test number: 7

Description: to confirm that a user can delegate a subset of their privileges to another user in the same group, but not with a greater delegation depth than they have been given (unlimited requested, but DIS limits it to 1 due to previous delegation in Test 4).

Requester: cn=aa1,ou=staff,o=permis,c=gb


RoleType: permisRole RoleValues: Professor

From: 2004.06.01 To: 2007.08.27

Assertion: can

Depth: 0

Reply:

Done|CN=aa2,OU=staff,O=permis,C=gb|permisRole:Professor| Jun 01 2004| Jan 01 2006|Holder can assert privileges|1

Test number: 8

Description: to confirm that the DIS enforces delegation policy, enforcing delegation

depth. Note that the delegate is no longer allowed to delegate further.



RoleType: permisRole RoleValues: Professor

From: 2004.06.01 To: 2007.08.27

Assertion: can

Depth: 0

Reply:

Done|CN=aa3,OU=staff,O=permis,C=gb|permisRole:Professor| Jun 01 2004| Jan 01 2006|Holder can assert privileges|-1

Test number: 9

Description: to confirm that the DIS enforces delegation policy, enforcing delegation depth and stopping a user delegating when he is not allowed to.



RoleType: permisRole RoleValues: Staff

From: 2004.06.01 To: 2007.08.27

Assertion: can

Depth: 0

Reply:


Test number: 10

Description: to confirm that the SOA can issue any AC to any entry in group 3 (student domain), delegation depth is 2 and maximum “From” and “To” time instances.


Holder: cn=student1,ou=student,o=permis,c=gb

RoleType: permisRole RoleValues: Student

From: 2004.06.10 To: 2007.08.27

Assertion: can

Depth: 2

Reply:

Done|CN=student1,OU=student,O=permis,C=gb|permisRole:Student| Jun 10 2004| Aug 27 2007|Holder can assert privileges|2

Test number: 11

Description: to confirm that the DIS will enforce the Delegation Policy and not assign attributes (roles) to users who are not allowed them, or for longer time periods than allowed. In this test one attribute value (Admin) is downgraded (to Professor) because it cannot be assigned to any staff in group 2, even though the delegator has the role. Also both the “From” and “To” time instances are constrained.



RoleType: permisRole RoleValues: Researcher, Admin

From: 2003.06.01 To: 2008.08.27

Assertion: can

Depth: 2

Reply:

Done|CN=aa1,OU=staff,O=permis,C=gb|permisRole: Professor, Researcher | Jun 1 2004| Aug 27 2007|Holder can assert privileges|2

Test number: 12

Description: to confirm that the DIS can issue an AC to a subject, when the requester is itself.

Requester: cn=dis,ou=admin,o=permis,c=gb


RoleType: permisRole RoleValues: Researcher

From: 2004.01.01 To: 2010.01.01

Assertion: cannot

Depth: 0

Reply:

Done|CN=aa2,OU=staff,O=permis,C=gb|permisRole:Researcher| Jun 01 2004| Aug 27 2007|Holder can not assert privileges|0

Test number: 13

Description: to confirm that the DIS can not issue an AC to itself when the requester is also itself.

Requester: cn=dis,ou=admin,o=permis,c=gb

Holder: cn=dis,ou=admin,o=permis,c=gb


From: 2006.01.01 To: 2009.01.01

Assertion: cannot

Depth: 0

Reply:


Test number: 14

Description: to confirm that a holder cannot delegate an AC to himself.



RoleType: permisRole RoleValues: Student, Researcher

From: 2004.06.01 To: 2007.08.27

Assertion: can

Depth: 2

Reply:


Test number: 15

Description: to confirm that subjects cannot delegate ACs to holders that are in a different subject domain.

Requester: cn=admin1,ou=admin,o=permis,c=gb



From: 2004.06.01 To: 2007.08.27

Assertion: can

Depth: 2

Reply:


Test number: 16

Description: to confirm that the DIS can not issue an AC when the holder is excluded from a subject domain.

Requester: cn=student1,ou=student,o=permis,c=gb



From: 2005.01.01 To: 2006.05.01

Assertion: can

Depth: 0

Reply:


Test number: 17

Description: to confirm that when a requester has two separate roles, delegated from different superiors, he cannot merge them into a single combined delegated credential. (Two separate delegations should be performed in order to stop the chains from cross linking.) Only the most superior role will be delegated in this request. When the two roles have the same superiority (Professor and Researcher) then the one with longer validity period will be used for delegation.



RoleType: permisRole RoleValues: Professor, Researcher

From: 2005.01.01 To: 2007.08.27

Assertion: can

Depth: 0

Reply:

Done|CN=aa4,OU=staff,O=permis,C=gb|permisRole:Researcher| Jan 01 2005| Aug 27 2007|Holder can assert privileges|0

Test number: 18

Description: to confirm that a subject can delegate to another subject in his domain, providing it is in accordance with the Delegation Policy. In this case, the “From” time and the delegation depth are downgraded.




From: 2004.03.01 To: 2007.08.27

Assertion: can

Depth: 2

Reply:

Done|CN=student2,OU=student,O=permis,C=gb|permisRole:Student| Jun 10 2004| Aug 27 2007|Holder can assert privileges|1

Test number: 19

Description: to confirm that a requester cannot delegate a privilege that he does not hold.




From: 2005.01.01 To: 2006.05.01

Assertion: can

Depth: 0

Reply:


REVOCATION TEST CASES:

For testing the revocation, you need to change the SearchRequestor parameter to “anyone”.

Test number: 20

Description: to confirm that a user that is out of all the subject domains can search and view any issued attributes.

Search attributes:

Requester: cn=external, o=permis, c=gb

Holder: cn=aa1, ou=staff, o=permis, c=gb

Reply:

ACs returned


Issuer: cn=dis, ou=admin, o=permis, c=gb

Issued on behalf of : cn=soa,ou=admin, o=permis, c=gb

Role(s): Professor, Researcher

and another AC:



Issued on behalf of : cn=soa,ou=admin, o=permis, c=gb

Role(s): Professor, Researcher

================================================================

Test number: 21

Description: an entry can search and view attributes of another entry which is in a different subject domain but can not revoke any of these attributes.

Search attributes:

Requester: cn=aa1, ou=staff, o=permis, c=gb

Holder: cn=student2, ou=student, o=permis, c=gb

ACs returned



Issued on behalf of : cn=student1, ou=student, o=permis, c=gb

Role(s): Student

(This AC was issued in test case 18)

Revoke the AC and the reply is:

You are not allowed to revoke an Attribute that you do not hold or did not issue

================================================================

Test number: 22

Description: to confirm that a user can revoke an attribute which was issued on his behalf.

Search attributes:



ACs returned



Issued on behalf of : cn=aa1, ou=staff, o=permis, c=gb

Role(s): Professor



Requested Attribute is revoked

================================================================

Test number: 23

Description: to confirm that a user can revoke an attribute issued to him by anyone

Search attributes:

Requester: cn=student2, ou=student, o=permis, c=gb


ACs returned



Issued on behalf of : cn=student1, ou=student, o=permis, c=gb

Role(s): Student




================================================================

Test number: 24

Description: to confirm that an issuer can revoke any attribute issued by it

Search attributes:

Requester: cn=dis, ou=admin, o=permis, c=gb

Holder: cn=admin1, ou=admin, o=permis, c=gb

ACs returned

Holder: cn=admin1, ou=admin o=permis, c=gb


Issued on behalf of : cn=SOA, ou=admin, o=permis, c=gb

Role(s): Admin




================================================================

Test number: 25

Description: to confirm that an attribute authority can revoke any attribute that it did not issue itself, if it has enough privileges to have issued that attribute.

Note. This feature is enabled so as to allow a manager to revoke the attributes of a staff member when the issuing manager is not available.

Search attributes:



ACs returned

Holder: cn=aa3, ou=staff o=permis, c=gb



Role(s): Professor




================================================================

Test number: 26

Description: to confirm that the SOA can revoke any attribute.

Search attributes:

Requester: cn=soa, ou=admin, o=permis, c=gb


ACs returned




Role(s): Researcher




Annex A. The Delegation Policy

The PERMIS Policy (X.509 PMI RBAC) is composed of a number of sub-policies and they are briefly presented below.

SubjectPolicy

The SubjectPolicy specifies the domains of users who may be granted roles and delegation privileges within the overall PMI policy. Subjects within a subject domain can delegate to other subjects in the same domain, but not to subjects in other domains (i.e. cross domain delegation is not allowed.) Each domain is specified as an LDAP subtree. In the testing policy, we have the following subject domains:

Domain ID="student" with LDAPDN="ou=student,o=permis,c=gb"but excluding “cn=student5,ou=student,o=permis,c=gb” and including “cn=dis,ou=admin,o=permis,c=gb”

(Note that the DIS needs to part of each subject domain that it is allowed to delegate in)

Domain ID="staff" with LDAPDN="ou=staff,o=permis,c=gb" and including “cn=dis, ou=admin,o=permis,c=gb”Domain ID="admin" with LDAPDN="ou=admin,o=permis,c=gb"

RoleHierarchyPolicy

The RoleHierarchyPolicy defines the role hierarchies that are supported by a specific RBAC policy. Each role hierarchy is specified as a set of Superior-Subordinates attribute values. Each superior role can have multiple subordinate roles, and each subordinate role may also be a superior. In the testing policy, we have the following role hierarchy:

SOAPolicy

The SOAPolicy lists the LDAPDNs of the Sources of Authority (SoAs) that are trusted to issue roles to the subjects specified in the subject policy. There is one entity that is trusted to issue roles to subjects in our test policy, and that is the policy creator (i.e. he only trusts himself!!).

SOA with ID="SOA" LDAPDN="cn=SOA, ou=admin, o=permis,c=GB"

RoleAssignmentPolicy

The RoleAssignmentPolicy specifies which roles can be assigned to which subjects by which SoAs. For each role assignment, we also specify whether the assigned roles can be delegated or not and whether there are any time constraints on the assignment. Following is the brief review of the RoleAssignmentPolicy in our testing policy.

The SOA is trusted to assign:

1. role "Student" to subjects in the "student" domain with validity time from 2004-06-10 to 2007-08-27,

2. roles "Staff", "Researcher" and "Professor" to subjects in the "staff" domain with validity time from 2004-06-01 to 2007-08-27,

3. role "Admin" to subjects in the "admin" domain with validity time from 2004-01-01 to 2010-01-1.

The SOA has unlimited delegation depth in the testing policy.

Delegation Policy in XML

<?xml version="1.0" encoding="UTF-8"?>





<!DOCTYPE X.509_PMI_RBAC_Policy>

<X.509_PMI_RBAC_Policy OID="1.2.826.0.1.3344810.6.0.0.1">

<SubjectPolicy>

<SubjectDomainSpec ID="student">

<Include LDAPDN="ou=student,o=permis,c=GB">

<Exclude LDAPDN="cn=student5,ou=student,o=permis,c=GB"/>

</Include><Include LDAPDN="cn=dis,ou=admin,o=permis,c=gb"/>

</SubjectDomainSpec>

<SubjectDomainSpec ID="staff">

<Include LDAPDN="ou=staff,o=permis,c=GB"/>

<Include LDAPDN="cn=dis,ou=admin,o=permis,c=gb"/></SubjectDomainSpec>

<SubjectDomainSpec ID="admin">

<Include LDAPDN="ou=admin,o=permis,c=GB"/>

</SubjectDomainSpec>

</SubjectPolicy>

<RoleHierarchyPolicy>

<RoleSpec Type="permisRole" OID="1.2.826.0.1.3344810.1.1.14">

<SupRole Value="Student">

</SupRole>

<SupRole Value="Staff">

<SubRole Value="Student"/>

</SupRole>

<SupRole Value="Professor">

<SubRole Value="Staff"/>

</SupRole>

<SupRole Value="Researcher">

<SubRole Value="Staff"/>

</SupRole>

<SupRole Value="Admin">

<SubRole Value="Professor"/>

<SubRole Value="Researcher"/>

</SupRole>

</RoleSpec>

</RoleHierarchyPolicy>

<SOAPolicy>

<SOASpec ID="SOA" LDAPDN="cn=SOA, ou=admin, o=permis,c=GB"/>

</SOAPolicy>

<RoleAssignmentPolicy>

<RoleAssignment>

<SubjectDomain ID="student"/>

<RoleList>

<Role Type="permisRole" Value="Student"/>

</RoleList>

<Delegate />

<SOA ID="SOA"/>

<Validity>

<Absolute Start="2004-06-10" End="2007-08-27"/>

</Validity>

</RoleAssignment>

<RoleAssignment>

<SubjectDomain ID="staff"/>

<RoleList>

<Role Type="permisRole" Value="Professor"/>

<Role Type="permisRole" Value="Staff"/>

<Role Type="permisRole" Value="Researcher"/>

</RoleList>

<Delegate />

<SOA ID="SOA"/>

<Validity>


</Validity>

</RoleAssignment>

<RoleAssignment>

<SubjectDomain ID="admin"/>

<RoleList>

<Role Type="permisRole" Value="Admin"/>

</RoleList>

<Delegate />

<SOA ID="SOA"/>

<Validity>


</Validity>

</RoleAssignment>

</RoleAssignmentPolicy>

</X.509_PMI_RBAC_Policy>

Documents

installation guide