*On Wed, Aug 17, 2016 at 10:31 AM, Richard Frovarp <[email protected] <[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. 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 [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/CAAUrXavM-a0X8fCPLyQNC%3D03ud52mikStq7mHG7ArfYBV-4vug%40mail.gmail.com. For more options, visit https://groups.google.com/a/apereo.org/d/optout.
