Moving due to other work in the way for CS.

Have progress on local machine.

1. Am able to specify two new parameters to the custom Realm to indicate the attribute name containing the user's certificate in LDAP and a label indicating what to search for to locate the UID of record in the incoming client auth certificate's Subject DN.

2. Was able to write simple code to extract the user certificate out of ldap and do a direct comparison between that certificate and the one sent in from the browser. This was done by getting the binary cert data from LDAP and converting it to a java.security.X509Certificate object, which is the object sent in from the browser by the lower level Tomcat Realm Code.

3. Did a simple test with our KRA where the KRA's admin certificate allowed access to one of the Rest Easy based servlets and alternatively, did not allow the CA's admin certificate access to the very same servlet in the KRA.

ToDO:

1. Might want to do some sort of cert validation on the incoming certificate if feasible.

2. Need to figure out how to perform authorization tasks based on roles in contrast to our current reliance on ACL based authorization.

Further progress locally:

1. Was able to set up the existing JNDI realm attributes in the new realm's entry in server.xml such that the existing user and group memberships encoded in our current LDAP server can be used to perform simple authorization checks. This is done by specifying security constraints in the server's web.xml file. Within the security constraint we can create "auth-constraint" entries that refer to security roles , which are established later in the web.xml. It turns out that multiple security constraints can be established with each given its own url mapping(s). This way we can call for different group memberships based on the servlet being accessed.

2. The current tomcat configuration only allows for one single "login-config" method per application. This means that if we want "ssl client auth" for the authentication method, it will be global to the application. Our current server support the notion of allowing optional authentication based on URL.

The beginnings of a solution to this problem turns out to lie in the creation of a custom "Authenticator" class. This class is configurable in the server.xml by establishing a "Valve" entry for it. This way the custom authenticator gets called instead of the single configured one.

Right now I only have a stub authenticator. Will have to determine what to do with this authenticator to get the behaviour we are after here.

Current progress:

Talked with Ade about initial progress. Some suggested changes being worked on:

1. Base the client authentication for the Realm upon the ldap field "description" instead of "UID".
   Have this working locally. The configuration can choose whether to go with "UID" or description.

2. Next we decided to provide support for our current ACL system. In the Realm and within a possible custom "Authenticator". In progress. Already have the ability to read the ACLs from the ldap db and we have come up with a simple scheme to use a file to map servlet patterns to ACL resource IDs and operations.
   Have rough code to demonstrate this as well. Further progress will tell if we need to have the Authenticator or everything can be done in the realm.

3. The current JNDI realm requires the directory manager privileges to access users groups and acls. Investigation to see if client auth ssl can be utilized for this.

4. When the current PKI realm searches for users, it makes use of a single searchBase path. We want to know if we can specify multiple search paths when looking for users. Either the base realm supports it or we will have to write the code for it.

Have it working such that the current DRMTest.java drm rest test client can talk SSL with client auth to the KRA, with a working PKIJNDI custom realm doing authentication and authz with our current security ACLs.

Need a bit of clean up and packaging.

Dogtag PKI is moving from Pagure issues to GitHub issues. This means that existing or new
issues will be reported and tracked through Dogtag PKI's GitHub Issue tracker.

This issue has been cloned to GitHub and is available here:
https://github.com/dogtagpki/pki/issues/641

If you want to receive further updates on the issue, please navigate to the
GitHub issue and click on Subscribe button.

Thank you for understanding, and we apologize for any inconvenience.