PERMIS Frequently Asked QuestionsAnswering team: Sassa Otenko firstname.lastname@example.org,
Prof. David Chadwick D.W.Chadwick@kent.ac.uk
What is PERMIS?
PERMIS is an authorisation infrastructure. Given the distinguished name of a user, a target that the user wishes to access, the mode of access, plus optional environmental parameters such as time of day, PERMIS will say whether the user is authorised to access the target or not.
An attribute is simply a property of an object. An attribute comprises a type and a value for example, attribute type = name, attribute value = John Smith, and attribute type = role, attribute value = project manager. A role is just one type of attribute that is typically used to signify the position that someone has in an organisation. Attribute certificates (ACs) are attributes that are certified by an Attribute Authority (AA) as belonging to a particular object. The AC is digitally signed by the AA to show this linkage. If you trust the AA, then you can trust that the object has the attribute specified in the AC. The international standard for attribute certificates is X.509(2001).
No. A user can authenticate to the PERMIS protected application using whatever mechanism the application supports e.g. Kerberos, username/password, RADIUS, etc. The only PERMIS user who should have a public key certificate is the SoA who writes the policy for the resource, in order to sign it. But even this is not necessary in the latest PERMIS release, since PERMIS will now accept unsigned policies.
PERMIS requires the Sources of Authority (SoA) to set the policies for every resource they own. A PERMIS policy says who the users are that are covered by the policy, what roles/attributes are supported, who is allowed to allocate the roles to the users, what resources are covered by the policy, what actions are supported by the resources (e.g. read, write, delete), and what privileges (actions on resources) are granted to each role. PERMIS then checks the X.509 ACs that are possessed by the user, and sees if these conform to the policy, and if they are sufficient to grant the access being requested.
Please check the following:
The Sun ONE/Sun Java Directory Server development team inform us this bug might be fixed in Sun ONE/Sun Java DS 5.2 patch 2. It is not fixed in earlier versions of DS.
The PKCS#12 file is encrypted using triple DES, which is too strong according to the US export law. The key size is not recognised by the Java Virtual Machine and that causes signing to fail. To allow the keys of bigger size, you need to install a different cryptography strength jurisdiction files.
See the bottom of Sun's download page for the jurisdiction files and installation instructions.
After this the ACM and PE will be able to sign the ACs.
This can be caused by one of the following reasons:
Use LDAP_AC_attribute parameter to configure the correct attribute type
(Some administrators pass PEM encoded Root CA PKC)
Last updated 20 July 2011