Need help with CAS/SSO/LDAP config on Tomcat 8

[Brad]

As a first exercise, I configured CAS 4.2.1 on Tomcat 8 / Java 8 using the Maven overlay, configuring the resulting cas.war and the sample Java client webapp (cas-sample-java-webapp) to authenticate against LDAP. I was able to get this working successfully. 

Now that I have this initial configuration working -- which essentially requires every new webapp to be individually configured to use CAS, I would like to transition to secure the entire Tomcat container to use CAS to authenticate against LDAP, such that all deployed webapps are secured with SSO, without requiring any specific configuration in the deployed webapps. I have seen references to this in older versions of the CAS / client documentation, but nothing that really shows definitively how to configure this, or to hit LDAP. I tried throwing a valve in the server's context.xml file as follows: 

  <Valve

    className="org.jasig.cas.client.tomcat.v8.Cas20CasAuthenticator"

    encoding="UTF-8"

    casServerLoginUrl="https://localhost:8443/cas/login"

    casServerUrlPrefix="https://localhost:8443/cas"

    serverName="localhost"

    />

But this just blows up Tomcat on startup -- every webapp startup fails. So I have two questions: 

1. At this point, is it even possible to set up CAS 4.2.1 on Java 8/Tomcat 8 to authenticate against LDAP using server-wide configuration (i.e. no deployed web-apps need CAS-specific configuration, in other words, any app deployed to that Tomcat instance will be secured behind LDAP-authenticated SSO)? 

2. If the answer to #1 is that yes, it is possible, how is this accomplished in Tomcat config? 

Thanks in advance for your help. 

Brad

[Brad]

Given the lack of any coverage on this in the documentation, and void of any reply here, is it a reasonable conclusion that there is no configuration to secure the entire Tomcat 8 container with CAS, and that the only option is securing each individual deployed app WAR via configuration within that WAR?

Any confirmation on this would be great. Of course, lack of any doc on configuration or general knowledge about it presents its own pragmatic support barrier to use even if it is possible, but it would be helpful to confirm whether it is possible or not regardless. 

Thanks in advance for any help. 

Brad

[Waldbieser, Carl]

Brad,

The way that SSL/TLS certificates work, that is more or less true.
If you have a wildcard cert for a domain, or a cert with multiple SANs, there might be some way to set a default, but that would be documented in the Tomcat project [1].

Personally, I dislike using Java's keytool, so I tend to let Tomcat or Jetty or whatever run without certificates and front them with a proxy that will do the encryption (e.g. Apache or Nginx). Then I can manage all my certs in PEM format, which I prefer.

Thanks,
Carl Waldbieser
ITS Systems Programmer
Lafayette College

[1] https://tomcat.apache.org/tomcat-8.0-doc/ssl-howto.html

--
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/68122a6f-b951-45c9-b38c-42c0448bbfdb%40apereo.org.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.

[Ray Bon]

Brad,

Sounds like you are looking for mod_auth_cas for tomcat. It could be useful but I have not heard of anything like this (though my exposure is limited).

Ray

--

[Richard Frovarp]

I'm guessing that such a thing wouldn't exist in Apache Tomcat. I'm not sure what you hope to gain by doing that. Surely each context / application is going to have its own security needs. CAS should just bring back enough information for Spring Security or Apache Shiro to take over for the rest of the application security. Spring and Shiro will quite nicely hand over to a CAS handler to force that authentication to CAS.

From my understanding, to have it on the container level would require shared session state amongst all of your contexts. If any of the apps serialize any specific information in to the session, it may be required that all of the apps/contexts have the same libraries to load that serialized information. Not sure how good of a job Tomcat does handling competing session writes from different contexts.

Simplest solution is to have each application be in charge of its own security, and use SSO so it is transparent to the end user.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/305955dc-a0cb-3a3a-bb82-3ae8a9dcdbe5%40uvic.ca.

[Brad O'Hearne]

On Wed, Aug 17, 2016 at 10:31 AM, Richard Frovarp <richard...@ndsu.edu> wrote:

I'm guessing that such a thing wouldn't exist in Apache Tomcat. I'm not sure what you hope to gain by doing that. Surely each context / application is going to have its own security needs. 

Thanks for the reply. For my case -- in general, the needs for the authentication mechanism for any deployed web app is identical: authentication against LDAP, success produces a token, subsequent requests validate token, etc. There should be no variation between web apps for how authentication works, the way a user is challenged for credentials, the resulting data structures, etc. 

The authorization mechanism to access a particular web app should be identical as well. Whether role- or group-based, the idea is the same -- proper membership should allow access to a web app. 

The configuration and management of both authentication and authorization to access a web app ideally would be managed centrally, in front- / outside- of any secured web apps (as far as user information goes, for my situation that would all be managed in LDAP). 

Where the security needs of different web apps diverge are in two areas: 

1. As you say, the management of session state. I would expect that if security enforcement occurred at the container level, it would probably be logical that app-specific session state was sand-boxed so other apps could not access it -- that would eliminate concurrency issues. Session state shared across apps is debatable, but if it were allowed, then obviously some synchronized access to state would be required, but the focus here wasn't really to figure out concurrency, but rather deployment and configuration. 
2. Authorization of behaviors within an app. In this case, an app would need to be provided access to identity-related authorization info by the container (via the session), and then it could conduct affairs for users as it saw fit for whatever the web app does. 
   

That was the idea, and I was hoping that CAS could handle that. Having to change source / configuration per each web app and rebuild / test / deploy isn't optimal. But if CAS can't handle that, knowing this is just as helpful. So thanks for your reply.....

Cheers, 

Brad

[Waldbieser, Carl]

Brad,

If you were using LDAP authentication, you'd typically still need to configure each web app separately with the LDAP client configuration. It is pretty much the same with CAS.
You could get around this in very specific cases, but not the general case.

For example, if all your web apps were behind a CAS-authenticating proxy, your CAS authN would be configured once and happen at the proxy. Your apps would presumably get the authenticated user passed to them by something like AJP or an HTTP header, etc. I don't know if you could do something like that with Apache + mod_auth_cas or not. Since a fair mix of our CAS clients are actually off-premise, and even on premise ones use different technology stacks, the CAS client configurations are typically managed by the individual application owners, so I have never had an occasion to try what you are suggesting.

Thanks,
Carl

----- Original Message -----
From: "Brad" <bohe...@flp.com>

To: "Richard Frovarp" <richard...@ndsu.edu>
Cc: cas-...@apereo.org
Sent: Wednesday, August 17, 2016 2:02:47 PM
Subject: Re: [cas-user] Re: Need help with CAS/SSO/LDAP config on Tomcat 8

*On Wed, Aug 17, 2016 at 10:31 AM, Richard Frovarp
<richard...@ndsu.edu <richard...@ndsu.edu>> wrote:*
>
> *I'm guessing that such a thing wouldn't exist in Apache Tomcat. I'm not

> sure what you hope to gain by doing that. Surely each context / application

> is going to have its own security needs. *

>

Thanks for the reply. For my case -- in general, the needs for the

authentication* mechanism* for any deployed web app is identical:

authentication against LDAP, success produces a token, subsequent requests
validate token, etc. There should be no variation between web apps for how
authentication works, the way a user is challenged for credentials, the
resulting data structures, etc.

The authorization *mechanism* to access a particular web app should be

identical as well. Whether role- or group-based, the idea is the same --
proper membership should allow access to a web app.

The configuration and management of both authentication and authorization
to access a web app ideally would be managed centrally, in front- /
outside- of any secured web apps (as far as user information goes, for my
situation that would all be managed in LDAP).

Where the security needs of different web apps diverge are in two areas:

1. As you say, the management of session state. I would expect that if

security enforcement occurred at the container level, it would probably be
logical that app-specific session state was sand-boxed so other apps could
not access it -- that would eliminate concurrency issues. Session state
shared across apps is debatable, but if it were allowed, then obviously
some synchronized access to state would be required, but the focus here
wasn't really to figure out concurrency, but rather deployment and
configuration.

2. Authorization of behaviors within an app. In this case, an app would

need to be provided access to identity-related authorization info by the
container (via the session), and then it could conduct affairs for users as
it saw fit for whatever the web app does.

That was the idea, and I was hoping that CAS could handle that. Having to
change source / configuration per each web app and rebuild / test / deploy
isn't optimal. But if CAS can't handle that, knowing this is just as
helpful. So thanks for your reply.....

Cheers,

Brad

--
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To post to this group, send email to cas-...@apereo.org.
Visit this group at https://groups.google.com/a/apereo.org/group/cas-user/.

To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/CAAUrXavM-a0X8fCPLyQNC%3D03ud52mikStq7mHG7ArfYBV-4vug%40mail.gmail.com.

[Richard Frovarp]

On 08/17/2016 01:02 PM, Brad O'Hearne wrote:

On Wed, Aug 17, 2016 at 10:31 AM, Richard Frovarp <richard...@ndsu.edu> wrote:

I'm guessing that such a thing wouldn't exist in Apache Tomcat. I'm not sure what you hope to gain by doing that. Surely each context / application is going to have its own security needs. 

Thanks for the reply. For my case -- in general, the needs for the authentication mechanism for any deployed web app is identical: authentication against LDAP, success produces a token, subsequent requests validate token, etc. There should be no variation between web apps for how authentication works, the way a user is challenged for credentials, the resulting data structures, etc. 

Using CAS standardizes all of this.

The authorization mechanism to access a particular web app should be identical as well. Whether role- or group-based, the idea is the same -- proper membership should allow access to a web app. 

Using the same libraries in your applications handles this. I've got a Apache Maven archetype that sets everything up for me automatically for new project creation. I just need to then decide on which paths are protected by which roles and permissions.

The configuration and management of both authentication and authorization to access a web app ideally would be managed centrally, in front- / outside- of any secured web apps (as far as user information goes, for my situation that would all be managed in LDAP). 

Right, CAS uses LDAP for authentication and attribute return for determining authorization.

Where the security needs of different web apps diverge are in two areas: 

1. As you say, the management of session state. I would expect that if security enforcement occurred at the container level, it would probably be logical that app-specific session state was sand-boxed so other apps could not access it -- that would eliminate concurrency issues. Session state shared across apps is debatable, but if it were allowed, then obviously some synchronized access to state would be required, but the focus here wasn't really to figure out concurrency, but rather deployment and configuration.
   

Authentication and authorization information is shared in the session. So this is what necessitates shared session state amongst all contexts.

1. Authorization of behaviors within an app. In this case, an app would need to be provided access to identity-related authorization info by the container (via the session), and then it could conduct affairs for users as it saw fit for whatever the web app does. 
   

That was the idea, and I was hoping that CAS could handle that. Having to change source / configuration per each web app and rebuild / test / deploy isn't optimal. But if CAS can't handle that, knowing this is just as helpful. So thanks for your reply.....

It's not CAS that can't handle it. I have no idea how you would get that work in Tomcat using any mechanism. Do you have it working now with LDAP? What you're asking is really a Tomcat problem. Your best bet for an answer on that would be to ask the Tomcat user mailing list over at the ASF. They have the experts on how you would use a single authentication and authorization method on a container and share that information with all contexts. If they have a good answer for that, from there it can be adopted to work with CAS.

You certainly could front it with HTTPD and use mod_auth_cas as suggested by Carl. HTTPD would manage the auth session, and present custom headers with attribute return info. From there the applications could make authorization decisions. You'd be working with custom headers, so you're rebuilding your code and/or putting auth handlers in each web.xml anyway.