This tutorial is based on the demonstration example. You have to download it and install all the relevant packages (see the list below) in order to be able to run it and to follow this example.
The following packages must be installed in your system for the PERMIS classes to be operational. You do not need to download anything extra for the example application, because it contains all the necessary packages going with it.
Refer to the Java manual on details of the usual package installation procedure. Here is just a short guideline.
You can install the packages by either:
The program will ask you to input your DN (it does
not authenticate your identity in any way, it is just a demo with no authentication),
and the target DN (target name you want to access) and the name of the
action you want to perform. After you have input the names, it will tell
you if the action is allowed or denied, or will report any errors it encounters.
Then it will repeat asking the user DN, target DN and the action name in
loop remembering your last input (just press Enter to confirm the last
value), until you input “.” as the user DN. In this way you can test various
combinations of the users, targets they are trying to access and the actions
they are attempting to perform. The policy for this test program is shown
in the table below:
|cn=user0,o=permis,c=gb||Any DN from the o=PERMIS,c=GB domain||Action0||0: action succeeded|
|cn=user0,o=permis,c=gb||Any DN from the o=PERMIS,c=GB domain||Action1||1: the action is not allowed|
|cn=user1,o=permis,c=gb||Any DN from the o=PERMIS,c=GB domain||Action0||1: the action is not allowed|
|cn=user1,o=permis,c=gb||Any DN from the o=PERMIS,c=GB domain||Action1||0: action succeeded|
|Any other DN from the o=PERMIS,c=GB domain (none of the above)||Any DN from the o=PERMIS,c=GB domain||Action0 or Action1||1: the action is not allowed|
|Any DN from the o=PERMIS,c=GB domain||Any DN from the o=PERMIS,c=GB domain||Action2||2: invalid input: Unacceptable Action for this Policy: Action2|
|Any DN from the o=PERMIS,c=GB domain||Any DN from the o=PERMIS,c=GB domain||Action3||0: action succeeded|
|Any DN from the o=PERMIS,c=GB domain||Any DN out of the o=PERMIS,c=GB domain||Any action||2: invalid input: Target is out of target domain|
|Any DN out of the o=PERMIS,c=GB domain||Any DN||Any action||2: invalid input: Failed to get credentials|
You can see that the OID of the policy is “1.2.822.214.171.12444810.6.0.0.3”. Don’t forget to change it when you decide to change the policy.
The Policy specifies one Subject domain with DN O=PERMIS,C=GB. It defines two roles of type permisRole, and which are not hierarchically connected: Role0 and Role1. It defines only one SOA: CN=SOA 1,O=PERMIS,C=GB. This is the only entity that is allowed to assign roles to users, and we see this statement in the Role Assignment Policy: the SOA can assign any role to any user from the specified domain.
The Policy also defines one Target domain with DN O=PERMIS,C=GB. There are three actions known: Action0, Action1 and Action3.
There are three target access statements that bind the permissions to the Roles. Thus it is allowed for a holder of Role0 to perform Action0 on any target, a holder of Role1 is allowed to invoke Action1 on any target, and anyone is allowed to call Action3 on any target. Note that the last statement concerns only those users that match the previously defined Subject domain.
If you inspect the users’ ACs, you will notice CN=User0,O=PERMIS,C=GB has been allocated Role0 and CN=User1,O=PERMIS,C=GB has been allocated Role1. These allocations define their privileges at run time.
Now try creating new ACs with roles in them, edit existing ACs, etc.
It does not matter what signature you put there, the sample code does not
verify it. Note that the new version of our Default Signing Utility for
the Privilege Allocator now lets you input the Issuer DN (previous versions
would not let you do that, which meant that by default you could not create
ACs that were understood by this sample code). Of course, if you have already
got the signing utility, you can just sign the ACs (but remember to change
the SOA name in the policy to your signing DN).
Example. Initialising Hashtables for multiple LDAP servers.
java.util.Hashtable  ldaps = new java.util.Hashtable[howManyLDAPsYouHaveGot];The last line of the example initialises the authorisation object in the same way, as it does in the sample code, only that instead of the VirtualRepository object filled in with ACs read in from files, it uses an LDAP repository (an array of parameters for them).
java.util.Hashtable env = new java.util.Hashtable();
// put your own URL there
// change the version, if you are not running v3 LDAP server
// otherwise it may sometimes retrieve it as a String
ldaps = env;
env = new java.util.Hashtable();
env.put(Context.SECURITY_PRINCIPAL, "cn=DSA Manager,c=GB");
ldaps = env;
PBAAPI pbaApi = new PermisRBAC(policyOID, soaDN, signatureVerifier, ldaps);
Now, before running your updated sample AEF, ensure the ACs are put in the proper entries of the LDAP directory (for example by using the Privilege Allocator). As soon as you place user certificates and the Policy AC in the directory, they will be picked up by the sample AEF.
Play with the program and see that it returns the same replies. The
only difference you may notice is replies for users with non-existing entries.
The sample AEF will say “cannot get credentials”, because it cannot handle
LDAP errors yet.
The object should return true only if the signature has been verified fine and a trust relationship has been established between the root of trust of the PKI and the signer. In all other cases it may either return false or throw a PkiException, depending on the circumstances and the design of the SignatureVerifier implementation.
Example. Embedding a SignatureVerifier.
SignatureVerifier pki = new SignatureVerifierUsingMyPKI(...);You can see now that it is pretty easy to enable PermisRBAC to use any PKI you have available.
// configure your signature verifier here
PBAAPI pbaApi = new PermisRBAC(policyOID, soaDN, pki, ldaps);
A nonfatal internal JIT (3.10.107(x)) error 'Relocation error: NULL relocation t arget' has occurred in : 'org/apache/crimson/parser/Parser2.maybeComment (Z)Z': Interpreting method. Please report this error in detail to http://java.sun.com/cgi-bin/bugreport.cg i