On 08/17/2016 01:02 PM, Brad O'Hearne wrote:
*/On Wed, Aug 17, 2016 at 10:31 AM, Richard Frovarp
<[email protected] <mailto:[email protected]>> 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.
--
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 [email protected].
To post to this group, send email to [email protected].
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/40957fc9-a422-7dbc-1059-df7142b0d75b%40ndsu.edu.
For more options, visit https://groups.google.com/a/apereo.org/d/optout.
