We need to come up with a set of requirements for extracting the Auth and Authz code from CS and into the Container based model supported in Tomcat through the use of Realms. The following is a rough list of some of the issues to be resolved:
Are we going to support cert auth and kerberos?
Is the so called Combined Realm approach going to work? From my research you can supply a list of sub Realms and the auth is attempted one at a time and when one succeeds, the user is authenticated.
For CS we kind of have two levels of authentication. 1) At the Connector level or socket level using "tomcatjss", which can be used to request SSL client auth. 2) Once the user passes that, the server itself has various authentication managers for specific certificate enrollment profiles based on what you are trying to do. For instance there are ldap based authentication, flat file based authentication, and certificate based authentication methods based on the certificate profile in use. Also, the server sometimes will ask for a certificate on the fly if required after initial negotiation. This kind of flexibility would be hard to simply rip out of the server and put into Realms. Will the Realms serve as an additional level of security to this or will it somehow replace it all? I would assume the goal would be to bring it all outside so it can be reused by others.
The server also supports and extensive AuthZ framework based on role users such as EE users and Agent, and Admin users. Each attempt to do something is checked against the mapped role user and a series of ACLs. Would all of this have to somehow be extracted out into the Realms? Looking at the JAAS Realm stuff, the notion of User and Role classes are part of the mix.
In looking at the Combined Realm approach, it appears to merely support the notion of falling back to the next method if the current method fails. In CS, we often dynamically choose the authentication method, how would this work? It looks like the Realm is only configurable one per Tomcat "Engine". This means all the supplies Connectors would be held to this on Realm or Combined Realm. Can we work with this?
Do we need some sort of JSS/NSS JAAS realm to support client auth? If so what would it do? What would become of the tomcatjss controlled listening sockets?
Was able to get simple LDAP based JNDI Realm working on Tomcat 6 against a simple sample web app. This required coming up with simple jsp's for a user and pword login screen and error screen. Also of note was the configuration needed in the webapp's own "web.xml" that required establishing a "<security-constraint>" element. Not sure if I got the role based settings correct in the JNDI realm, but the Realm operated properly in that it allowed the one legal user/password combo represented in the LDAP server and it rejected any other user/password combinations.
Performed some investigation:
Looks like the Realm is mainly interested in databases of users and roles. The actual SSL functionality is configured in the Connector regardless whether we are using our own TomcatJSS or the built in cert functionality.. TomcatJSS gives us NSS certs and keys by implementing the "SSLProvider" interface that is an undocumented config parameter for the Connector item.
Having said that, there appears to be a way to have a Realm and SSL Client auth to co-exist. The most obvious way to do this is to use the JAAS Realm. This type of Realm allows us to write custom "LoginModule" plugins that appear to have a way to get a hold of the input credentials. The most often case is Form based or Basic auth with username and password. There is an auth type called "CLIENT-CERT" which should allow us to obtain the cert and identity of the user and authenticate any way we see fit with some possible custom code. For instance, our code right now does an actual binary comparison between the incoming cert and the cert that is included in the user record in LDAP. This functionality might be a good candidate for the plugin. It is not obvious if the SSL client auth can co-exist with the LDAP centric JNDI Realm interface supported by Tomcat.
We know what we want to do here. Bring as much of the auth functionality from the internal server outside into a Tomcat Realm. The plan is to use the current tomcatjss SSL functionality at the Connector level and provide a custom Tomcat Realm to provide the SSL client auth functionality.
The first phase is to provide basic client cert auth functionality in the Realm. The next phase will be to attempt (if possible) move some of the internal ACL based authz functionality out into the Realm. Right now the current server makes a java code based checked at each servlet against the role of the incoming user.
Kerberos support has been punted to a later release.
Metadata Update from @jmagne: - Issue assigned to jmagne - Issue set to the milestone: m1
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/583
If you want to receive further updates on the issue, please navigate to the GitHub issue and click on Subscribe button.
Subscribe
Thank you for understanding, and we apologize for any inconvenience.
Login to comment on this ticket.