PERMIS Project Web Site

PERMIS Contents

Home

Essentials Integration Projects Documents Developers Get Involved 		PERMIS Frequently Asked QuestionsAnswering team: Sassa Otenko o.otenko@kent.ac.uk, Prof. David Chadwick D.W.Chadwick@kent.ac.uk

What is PERMIS?
What is the difference between roles, attributes and attribute certificates?
Does a user who possesses an X.509 attribute certificate also need to have an X.509 public key certificate (digital id) as well?
How does PERMIS work?
I can't get the Attribute Certificate Manager (ACM) or Policy Editor (PE) to write ACs to my LDAP server
I can't get the ACM or PE to sign ACs. I am using Java Runtime Environment 1.4
PERMIS RBAC Authorisation fails to set up with an error message saying "No policy with OID x.x.x was found for cn=x,o=y,c=z SOA"

  1. What is PERMIS?

    2. 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.
     
  2. What is the difference between roles, attributes and attribute certificates?

    3. 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).
     
  3. Does a user who possesses an X.509 attribute certificate also need to have an X.509 public key certificate (digital id) as well?

    4. 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.
     
  4. How does PERMIS work?

    5. 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.
     
  5. I can't get the Attribute Certificate Manager (ACM) or Policy Editor (PE) to write ACs to my LDAP server

    6. Please check the following:
    • Can you contact your LDAP server using a standard LDAP browser (e.g. Netscape or Microsoft Search for People) and retrieve entries from it? This will show that you don't have any connectivity or firewall problems.
    • Did you modify the schema of the LDAP server to allow X.509 ACs to be stored in the entries, by adding the PMI object class?
    • Does the entry already exist in the LDAP server? Remember that the ACM and PE do not create entries, they only add ACs to existing entries.
    • How is authentication to be done with the LDAP server. If for example SSL is required, this could cause a problem. It would be best to switch to simple password authentication before trying again.
    • Have you set the access controls on the entry so that the ACM and PE can write to the entry?
    • Some LDAP servers have bugs. Specifically, Sun ONE/Sun Java System Directory Server (DS v5.2 and earlier) does not fully conform to RFC 1777 and RFC 2251 (LDAPv2 and LDAPv3 respectively) in that it does not allow the client to use object identifiers (OIDs) to identify attributes such as the attributeCertificateAttribute when adding them to an entry (specifically it cannot support 2.5.4.58;binary). The PERMIS ACM and PE tools allow the value of this attribute to be configurable. It should be the name of the attribute type in your iPlanet schema whose OID is 2.5.4.58 (it is usually the attributeCertificateAttribute attribute type). Append ";binary" to the attribute type name for v3 LDAP servers.

      • 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.
  6. I can't get the ACM or PE to sign ACs. I am using Java Runtime Environment 1.4

    7. 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.

  7. PERMIS RBAC Authorisation fails to set up with an error message saying "No policy with OID x.x.x was found for cn=x,o=y,c=z SOA"

    8. This can be caused by one of the following reasons:
    • No Policy AC could be retrieved
      • Check that LDAP can be connected (e.g. there is no firewall rule forbidding that, and that anonymous users can read any entry)
      • Check that SoA's entry contains the Policy AC (e.g. use ACM to open the AC, and proof read the contents of the AC)
      • Check that PERMIS RBAC is told to use the correct attribute type (old OpenLDAPs require ";binary", new OpenLDAPs reject requests with ";binary", LDAP servers from other vendors may have schema specifics that require the attribute to be retrieved by its OID, or they use a different attribute type)

        •  

         

        Use LDAP_AC_attribute parameter to configure the correct attribute type

    • No well-formed AC was found
      • Check that the policy AC is self-signed (SoA's DN is in the Holder field, and SoA is the Issuer of the AC)
      • Check that the policy AC contains the pmiXMLPolicyAttribute with the policy in it
      • Check that the policy AC is well-formed (no data corruption occured)
    • Signature verification failed
      • To test this, remove ROOTCA parameter from the configuration file. If PERMIS Authorisation fails to start, this is not because of signature verification; look for other causes
      • Make sure ROOTCA points to the DER-encoded X.509 Public Key Certificate of the CA that signed the PKC of the SoA. (You can test signature verification on the Policy AC by providing the SoA's PKC directly instead of the Root CA's PKC)

        •  

         

        (Some administrators pass PEM encoded Root CA PKC)

      • Make sure that the SoA's PKC can be validated (either it is signed by the Root CA, or it is specified directly as the ROOTCA)
      • Check that the SoA's PKC is available in the LDAP (it should be stored in the userCertificate attribute in the SoA's entry)
    • Policy is syntactically or semantically incorrect
      • Use the Policy Editor to write the policies
      • Validate against the policy DTD
      • Check that the policy has the OID that you specified in the configuration
      • Check that the Role Hierarchy does not have loops
      • Check that the URLs used in the Policy are well-formed (check that the protocol names are known to PERMIS Authorisation - http:, https:. file:, ldap: and shib: URLs are supported by default; other protocols must be configured in programmatically)
      • Check that the IF-statement, if any, consists of valid expressions (types of operands and operators are known to PERMIS, and that the format of the values is valid - Integer, String, Boolean, and Time types are supported, EQ, LE, GE, LT, GT are supported by default; other types and operators must be configured in programmatically)
Last updated 20 July 2011