12:10 p.m.
One issue I have been looking at recently is how to integrate PKI and
IPA at the auth level while keeping a clean separation.
We can extract the authentication from the servlet code, so it is
purely a matter of configuring the Tomcat instance Realm.
I wrote up a Proof of concept for just doing pure LDAP using simple
bind, which is not a bad starting point.
http://adam.younglogic.com/2011/11/tomcat-simple-ipa/
We want to continue this approach, but use a more secure authentication
method. We won't be using basic auth, and we won't be using simple bind.
There are two forms of authentication we want to support: Client
Certificates and Kerberos. Certificates will work as they do now, and
Kerberos will be for passing through user credentials from IPA, through
HTTP to CS. In both cases, the data that backs it will be stored in
the DS instance.
Tomcat has a class classed a CombinedRealm:
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm
That might support stacking Certificate and Kerberos auth on top of
each other. The Realm will then delegate to LDAP for extracting the Roles.
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm
Kerberos is typically done using a JAAS Realm. I have to admit I don't
really like the fact that we have to modify the JVM startup to do so, it
is not really that big of a deal. I was also not a fan of setting the
Realm up as a single service ticket until Simo informed me that the
Browser NEGOTIATE mechanism assumes that the Service ticket is going to
be Named HTTP. This means that for Proxied implementations, to include
IPA, we will have to share the Service Principal Identity with the
Apache HTTPD server.
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm
However, once you start digging in, you will find that the solutions
are suboptimal. It turns out that the Negotiate auth-method has only
very recently been supported, and that is only on Tomcat7.
The best resource I have found on the options for a custom realm is here:
http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos
and the most likely option
http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule
We really want a mix of the KRB5Login Module and the JNDIRealm. That
seems to be what is described here:
http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with
Tomcat-7.
I suspect that the CombinedRealm approach will not support falling back
from one auth-method to another: I've been looking and have not see it
specified that you can put multiple auth-method entries inside a
login-config in the web.xml. Ideally, we would attempt a Certificate
based authentication first, and then fall back to Negotiate. However,
we can say that a given deployment is going to be either Kerberos or
Client Certificate, and swap out the configuration at the Tomcat
level. I don't like that nearly as much.
The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback
talks about how to do Client Cert with a fallback to Form based
authentication. We'd want to do Client Cert with a fallback to Krb5.
This is using what is called a Valve. In Tomcat 6 and 7 valves have
been deprecated in favor of Filters. The general approach is the same.
I'd like to keep the idea of the Realm as the primary approach. If we
do have to build a custom Realm, and I suspect that we will, we might
want to spin it off into its own package, or submit it for Inclusion in
Tomcat 7 upstream.
It seems that the PKI approach has been to Bind as Directory Manager.
What I would like to target moving forward is that the Bind is done as
the user making the web request. For managed operations that require a
higher level of authentication, we use the concept of queues like we do
now. The threads that manage those queue will use a Principal with a
higher level of authorization: not "Directory Manger", but perhaps "CA
Manager" which is a user we create that manages the CA subtree in the
Directory server. For a Dogtag deployment without IPA, the CA Manger
would have write privileged on the Identity subtree. For integrated
deployments, IPA would have its own principal "IPA Manager" that
would not have read or write capabilities in the CA Subtree. DRM,
TKS and other subsytems would in turn also get their own Manager users,
and they would only have permissions to manage their own trees: we will
need to clear up which gets read and write permissions on which other
subtrees.
Directory Manager would be limited to performing operations that effect
the entire DS instance: Setup and Replication.
The Directory Manager, CA Manager, IPA manager users should be binding
with a certificate or a keytab, not with a cleartext password.
9:04 p.m.
New subject: [Freeipa-devel] Tomcat Realms and Directory Server
Hi Adam,
I haven't replied to this summary so far for 2 reasons.
I had little time to ponder it (and Java is not my forte) and it is
still a bit up in the air.
I am a bit concerned about the relatively unstable/young support for
some of the tech that would have to be involved, but on the other hand I
tend to like the approach of better in depth security, auth forwarding,
and isolation of instances and credentials used.
I think you should keep exploring this area and see what works and what
not.
I wonder if the session work we are doing for the main IPA framework can
be used in some way to simplify part of the work you are doing.
Unfortunately working in Java may be an obstacle in this sense as we
plan to use python native marchalling/unmarshalling of objects in the
session cache, but keep in mind this may be an avenue to offload most of
the auth/session management work to the IPA framework and simplify your
credential management at least when dogtag is integrated with IPA.
Simo.
On Tue, 2011-11-08 at 13:10 -0500, Adam Young wrote:
One issue I have been looking at recently is how to integrate PKI
and
IPA at the auth level while keeping a clean separation.
We can extract the authentication from the servlet code, so it is
purely a matter of configuring the Tomcat instance Realm.
I wrote up a Proof of concept for just doing pure LDAP using simple
bind, which is not a bad starting point.
http://adam.younglogic.com/2011/11/tomcat-simple-ipa/
We want to continue this approach, but use a more secure authentication
method. We won't be using basic auth, and we won't be using simple bind.
There are two forms of authentication we want to support: Client
Certificates and Kerberos. Certificates will work as they do now, and
Kerberos will be for passing through user credentials from IPA, through
HTTP to CS. In both cases, the data that backs it will be stored in
the DS instance.
Tomcat has a class classed a CombinedRealm:
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm
That might support stacking Certificate and Kerberos auth on top of
each other. The Realm will then delegate to LDAP for extracting the Roles.
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm
Kerberos is typically done using a JAAS Realm. I have to admit I don't
really like the fact that we have to modify the JVM startup to do so, it
is not really that big of a deal. I was also not a fan of setting the
Realm up as a single service ticket until Simo informed me that the
Browser NEGOTIATE mechanism assumes that the Service ticket is going to
be Named HTTP. This means that for Proxied implementations, to include
IPA, we will have to share the Service Principal Identity with the
Apache HTTPD server.
http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm
However, once you start digging in, you will find that the solutions
are suboptimal. It turns out that the Negotiate auth-method has only
very recently been supported, and that is only on Tomcat7.
The best resource I have found on the options for a custom realm is here:
http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos
and the most likely option
http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule
We really want a mix of the KRB5Login Module and the JNDIRealm. That
seems to be what is described here:
http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with
Tomcat-7.
I suspect that the CombinedRealm approach will not support falling back
from one auth-method to another: I've been looking and have not see it
specified that you can put multiple auth-method entries inside a
login-config in the web.xml. Ideally, we would attempt a Certificate
based authentication first, and then fall back to Negotiate. However,
we can say that a given deployment is going to be either Kerberos or
Client Certificate, and swap out the configuration at the Tomcat
level. I don't like that nearly as much.
The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback
talks about how to do Client Cert with a fallback to Form based
authentication. We'd want to do Client Cert with a fallback to Krb5.
This is using what is called a Valve. In Tomcat 6 and 7 valves have
been deprecated in favor of Filters. The general approach is the same.
I'd like to keep the idea of the Realm as the primary approach. If we
do have to build a custom Realm, and I suspect that we will, we might
want to spin it off into its own package, or submit it for Inclusion in
Tomcat 7 upstream.
It seems that the PKI approach has been to Bind as Directory Manager.
What I would like to target moving forward is that the Bind is done as
the user making the web request. For managed operations that require a
higher level of authentication, we use the concept of queues like we do
now. The threads that manage those queue will use a Principal with a
higher level of authorization: not "Directory Manger", but perhaps "CA
Manager" which is a user we create that manages the CA subtree in the
Directory server. For a Dogtag deployment without IPA, the CA Manger
would have write privileged on the Identity subtree. For integrated
deployments, IPA would have its own principal "IPA Manager" that
would not have read or write capabilities in the CA Subtree. DRM,
TKS and other subsytems would in turn also get their own Manager users,
and they would only have permissions to manage their own trees: we will
need to clear up which gets read and write permissions on which other
subtrees.
Directory Manager would be limited to performing operations that effect
the entire DS instance: Setup and Replication.
The Directory Manager, CA Manager, IPA manager users should be binding
with a certificate or a keytab, not with a cleartext password.
_______________________________________________
Freeipa-devel mailing list
Freeipa-devel(a)redhat.com
https://www.redhat.com/mailman/listinfo/freeipa-devel
--
Simo Sorce * Red Hat, Inc * New York
9:39 a.m.
New subject: [Freeipa-devel] Tomcat Realms and Directory Server
On 12/01/2011 10:04 PM, Simo Sorce wrote:
Hi Adam,
I haven't replied to this summary so far for 2 reasons.
I had little time to ponder it (and Java is not my forte) and it is
still a bit up in the air.
I am a bit concerned about the relatively unstable/young support for
some of the tech that would have to be involved, but on the other hand I
tend to like the approach of better in depth security, auth forwarding,
and isolation of instances and credentials used.
I think you should keep exploring this area and see what works and what
not.
I wonder if the session work we are doing for the main IPA framework can
be used in some way to simplify part of the work you are doing.
Unfortunately working in Java may be an obstacle in this sense as we
plan to use python native marchalling/unmarshalling of objects in the
session cache, but keep in mind this may be an avenue to offload most of
the auth/session management work to the IPA framework and simplify your
credential management at least when dogtag is integrated with IPA.
Simo.
So I've learned a litle bit more since I wrote this. The Proxy code
should forward over the Principal, to the Java side. So we can rely on
AJP to do the authentication, and just treat as unauthenticated any
that come through without a Principal. There is a little risk here if a
system is misconfigured that someone could talk directly to AJP, so we
should look into securing the connection between Apache and Tomcat.
If we need to keep session information around in the Java side, we can
either add our own Session cookie, or store it in the Apache session.
Right now, the only need for that I've seen is CRSF Nonces, which are
currently disabled due to how IPA talks to Dogtag. We should probably
re-enable them incase if anyone wants to talk to the PKI server
directly, and provide an exception for IPA to do the work it needs for
requesting certificates
On the Tomcat side, we would still do JNDI LDAP for getting the
Subjects,just using the principal forwarded from AJP.
On Tue, 2011-11-08 at 13:10 -0500, Adam Young wrote:
> One issue I have been looking at recently is how to integrate PKI and
> IPA at the auth level while keeping a clean separation.
>
> We can extract the authentication from the servlet code, so it is
> purely a matter of configuring the Tomcat instance Realm.
>
> I wrote up a Proof of concept for just doing pure LDAP using simple
> bind, which is not a bad starting point.
>
> http://adam.younglogic.com/2011/11/tomcat-simple-ipa/
>
>
> We want to continue this approach, but use a more secure authentication
> method. We won't be using basic auth, and we won't be using simple bind.
>
> There are two forms of authentication we want to support: Client
> Certificates and Kerberos. Certificates will work as they do now, and
> Kerberos will be for passing through user credentials from IPA, through
> HTTP to CS. In both cases, the data that backs it will be stored in
> the DS instance.
>
> Tomcat has a class classed a CombinedRealm:
> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#CombinedRealm
>
> That might support stacking Certificate and Kerberos auth on top of
> each other. The Realm will then delegate to LDAP for extracting the Roles.
>
> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm
>
> Kerberos is typically done using a JAAS Realm. I have to admit I don't
> really like the fact that we have to modify the JVM startup to do so, it
> is not really that big of a deal. I was also not a fan of setting the
> Realm up as a single service ticket until Simo informed me that the
> Browser NEGOTIATE mechanism assumes that the Service ticket is going to
> be Named HTTP. This means that for Proxied implementations, to include
> IPA, we will have to share the Service Principal Identity with the
> Apache HTTPD server.
>
> http://tomcat.apache.org/tomcat-6.0-doc/realm-howto.html#JAASRealm
>
> However, once you start digging in, you will find that the solutions
> are suboptimal. It turns out that the Negotiate auth-method has only
> very recently been supported, and that is only on Tomcat7.
>
> The best resource I have found on the options for a custom realm is here:
> http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberos
> and the most likely option
> http://wiki.wsmoak.net/cgi-bin/wiki.pl?TomcatKerberosLoginModule
>
> We really want a mix of the KRB5Login Module and the JNDIRealm. That
> seems to be what is described here:
> http://tomcat.apache.org/tomcat-7.0-doc/windows-auth-howto.html
>
> We should target Tomcat 7 for Dogtag:future. Fedora 16 ships with
> Tomcat-7.
>
> I suspect that the CombinedRealm approach will not support falling back
> from one auth-method to another: I've been looking and have not see it
> specified that you can put multiple auth-method entries inside a
> login-config in the web.xml. Ideally, we would attempt a Certificate
> based authentication first, and then fall back to Negotiate. However,
> we can say that a given deployment is going to be either Kerberos or
> Client Certificate, and swap out the configuration at the Tomcat
> level. I don't like that nearly as much.
>
> The document here: http://wiki.apache.org/tomcat/SSLWithFORMFallback
> talks about how to do Client Cert with a fallback to Form based
> authentication. We'd want to do Client Cert with a fallback to Krb5.
> This is using what is called a Valve. In Tomcat 6 and 7 valves have
> been deprecated in favor of Filters. The general approach is the same.
>
> I'd like to keep the idea of the Realm as the primary approach. If we
> do have to build a custom Realm, and I suspect that we will, we might
> want to spin it off into its own package, or submit it for Inclusion in
> Tomcat 7 upstream.
>
> It seems that the PKI approach has been to Bind as Directory Manager.
> What I would like to target moving forward is that the Bind is done as
> the user making the web request. For managed operations that require a
> higher level of authentication, we use the concept of queues like we do
> now. The threads that manage those queue will use a Principal with a
> higher level of authorization: not "Directory Manger", but perhaps
"CA
> Manager" which is a user we create that manages the CA subtree in the
> Directory server. For a Dogtag deployment without IPA, the CA Manger
> would have write privileged on the Identity subtree. For integrated
> deployments, IPA would have its own principal "IPA Manager" that
> would not have read or write capabilities in the CA Subtree. DRM,
> TKS and other subsytems would in turn also get their own Manager users,
> and they would only have permissions to manage their own trees: we will
> need to clear up which gets read and write permissions on which other
> subtrees.
>
> Directory Manager would be limited to performing operations that effect
> the entire DS instance: Setup and Replication.
>
> The Directory Manager, CA Manager, IPA manager users should be binding
> with a certificate or a keytab, not with a cleartext password.
>
> _______________________________________________
> Freeipa-devel mailing list
> Freeipa-devel(a)redhat.com
> https://www.redhat.com/mailman/listinfo/freeipa-devel
4528
days inactive
4552
days old
2 comments
2 participants
participants (2)
-
Adam Young -
Simo Sorce