CAS (or single sign on): how to?

[Sam Zilverberg <sa...@gmail.com>]

Hi,

Our base wicket app is deploy around 40-50 times on a couple of tomcats.
Each instance has a different configuration but the code base is the same
app.
Each instance has its own context and it looks something like this:
app a : baseurl/a
app baba: baseurl/baba

Currently the authentication and authorization for each site is handled by
the wicket app assigned to that context.
We implemented IAuhorizationStrategy and are using the signin page from the
examples + captcha after a couple of tries.

We want an app at baseurl/login that will take care of loging in instead of
all the different apps doing it for themselves.
Whats the best way to implement such a CAS mechanism? (preferably using
wicket, spring is ok too)

Thanks,
Sam.

Re: CAS (or single sign on): how to?

[Dan Retzlaff <dr...@gmail.com>]

Hi, Sam. Responses inline.

On Tue, Feb 14, 2012 at 12:07 AM, Sam Zilverberg <sa...@gmail.com>wrote:

> 1) Do you use the "RestartResponseAtInterceptPageException" to redirect
> users to the cas site when the user is not logged in and the cookie is not
> present, or something else?
> 2) Do you allow loging in also through the "normal" sites, not using the
> cas?
>

We do not have a single authentication application; each application has
the ability to authenticate the user and create the site-wide cookie. That
said, yes, we use RestartResponseAtInterceptPage in that situation.


> 3) Shared data store - is this a wicket/java object or just any
> resource(like db) that both apps have access to?


We use a relational database. I intentionally left my statement vague,
though, since depending on your deployment there are multiple viable
approaches to sharing the set of active sessions.


> 4) Did you override some of wicket session store methods to support the
> extraction of the id from the shared data store?
>

I assume you mean "id *for* the shared data store", and no it's just
o.a.w.Session.get().getId() which is public. I don't know why we selected
that unique ID though; it's really arbitrary.


> 5) Session expiration -where do you add a session expiration listener? on
> the wicket app level or in the web.xml?
>

We use web.xml. The only reason ISessionStore#registerUnboundListener()
didn't work is because we needed to grab something out of the underlying
HttpSession which isn't exposed to UnboundListeners. But that requirement
is unique to our app.

For further context, we use this to allow customization of our application
on a client-by-client basis. Most of our clients use our "generic" app, but
we can extend the app with custom development for larger/paying clients
while minimizing impact to shared functionality. These clients can
authenticate from the generic login page, and then get HTTP redirected and
immediately logged into their custom app.

Hope that helps!

Dan


> On Tue, Feb 14, 2012 at 12:58 AM, Dan Retzlaff <dr...@gmail.com>
> wrote:
>
> > Hi Sam,
> >
> > We have a similar use case, and we use a home-grown approach within
> Wicket:
> > 1. The authenticating application persists a session ID into a shared
> data
> > store, and puts the ID into a new site-wide cookie. We use Wicket's
> > Session#getId() for the ID, but could equivalently use UUID.randomUUID().
> > 2. When other apps' IAuthorizationStrategy detects an
> > unauthorized/unauthenticated request, it tries to authenticate using this
> > site-wide cookie. It basically just verifies that the session ID in the
> > cookie corresponds to an active session in the shared data store.
> >
> > One thing to consider is your session expiration/logout logic. Our use
> case
> > is more like "user handoff" than concurrent Wicket sessions, and we have
> a
> > session expiration listener that invalidates the session in the shared
> data
> > store from the "owning" application. If your use case is not so simple,
> > then you'll have to define your own site-wide authentication expiration
> > event(s).
> >
> > On Mon, Feb 13, 2012 at 1:55 PM, Sam Zilverberg <samzilverberg@gmail.com
> > >wrote:
> >
> > > Hi,
> > >
> > > Our base wicket app is deploy around 40-50 times on a couple of
> tomcats.
> > > Each instance has a different configuration but the code base is the
> same
> > > app.
> > > Each instance has its own context and it looks something like this:
> > > app a : baseurl/a
> > > app baba: baseurl/baba
> > >
> > > Currently the authentication and authorization for each site is handled
> > by
> > > the wicket app assigned to that context.
> > > We implemented IAuhorizationStrategy and are using the signin page from
> > the
> > > examples + captcha after a couple of tries.
> > >
> > > We want an app at baseurl/login that will take care of loging in
> instead
> > of
> > > all the different apps doing it for themselves.
> > > Whats the best way to implement such a CAS mechanism? (preferably using
> > > wicket, spring is ok too)
> > >
> > > Thanks,
> > > Sam.
> > >
> >
>

Re: CAS (or single sign on): how to?

[Sam Zilverberg <sa...@gmail.com>]

A couple of implementation questions:

1) Do you use the "RestartResponseAtInterceptPageException" to redirect
users to the cas site when the user is not logged in and the cookie is not
present, or something else?
2) Do you allow loging in also through the "normal" sites, not using the
cas?
3) Shared data store - is this a wicket/java object or just any
resource(like db) that both apps have access to?
4) Did you override some of wicket session store methods to support the
extraction of the id from the shared data store?
5) Session expiration -where do you add a session expiration listener? on
the wicket app level or in the web.xml?

Thanks a lot for the help so far.
I started looking this kind of info a couple of days ago but couldn't find
anything useful.
I only found info about implementation using the container (tomcat) or
spring-security (which i don't use).

On Tue, Feb 14, 2012 at 12:58 AM, Dan Retzlaff <dr...@gmail.com> wrote:

> Hi Sam,
>
> We have a similar use case, and we use a home-grown approach within Wicket:
> 1. The authenticating application persists a session ID into a shared data
> store, and puts the ID into a new site-wide cookie. We use Wicket's
> Session#getId() for the ID, but could equivalently use UUID.randomUUID().
> 2. When other apps' IAuthorizationStrategy detects an
> unauthorized/unauthenticated request, it tries to authenticate using this
> site-wide cookie. It basically just verifies that the session ID in the
> cookie corresponds to an active session in the shared data store.
>
> One thing to consider is your session expiration/logout logic. Our use case
> is more like "user handoff" than concurrent Wicket sessions, and we have a
> session expiration listener that invalidates the session in the shared data
> store from the "owning" application. If your use case is not so simple,
> then you'll have to define your own site-wide authentication expiration
> event(s).
>
> On Mon, Feb 13, 2012 at 1:55 PM, Sam Zilverberg <samzilverberg@gmail.com
> >wrote:
>
> > Hi,
> >
> > Our base wicket app is deploy around 40-50 times on a couple of tomcats.
> > Each instance has a different configuration but the code base is the same
> > app.
> > Each instance has its own context and it looks something like this:
> > app a : baseurl/a
> > app baba: baseurl/baba
> >
> > Currently the authentication and authorization for each site is handled
> by
> > the wicket app assigned to that context.
> > We implemented IAuhorizationStrategy and are using the signin page from
> the
> > examples + captcha after a couple of tries.
> >
> > We want an app at baseurl/login that will take care of loging in instead
> of
> > all the different apps doing it for themselves.
> > Whats the best way to implement such a CAS mechanism? (preferably using
> > wicket, spring is ok too)
> >
> > Thanks,
> > Sam.
> >
>

Re: CAS (or single sign on): how to?

[Dan Retzlaff <dr...@gmail.com>]

Hi Sam,

We have a similar use case, and we use a home-grown approach within Wicket:
1. The authenticating application persists a session ID into a shared data
store, and puts the ID into a new site-wide cookie. We use Wicket's
Session#getId() for the ID, but could equivalently use UUID.randomUUID().
2. When other apps' IAuthorizationStrategy detects an
unauthorized/unauthenticated request, it tries to authenticate using this
site-wide cookie. It basically just verifies that the session ID in the
cookie corresponds to an active session in the shared data store.

One thing to consider is your session expiration/logout logic. Our use case
is more like "user handoff" than concurrent Wicket sessions, and we have a
session expiration listener that invalidates the session in the shared data
store from the "owning" application. If your use case is not so simple,
then you'll have to define your own site-wide authentication expiration
event(s).

On Mon, Feb 13, 2012 at 1:55 PM, Sam Zilverberg <sa...@gmail.com>wrote:

> Hi,
>
> Our base wicket app is deploy around 40-50 times on a couple of tomcats.
> Each instance has a different configuration but the code base is the same
> app.
> Each instance has its own context and it looks something like this:
> app a : baseurl/a
> app baba: baseurl/baba
>
> Currently the authentication and authorization for each site is handled by
> the wicket app assigned to that context.
> We implemented IAuhorizationStrategy and are using the signin page from the
> examples + captcha after a couple of tries.
>
> We want an app at baseurl/login that will take care of loging in instead of
> all the different apps doing it for themselves.
> Whats the best way to implement such a CAS mechanism? (preferably using
> wicket, spring is ok too)
>
> Thanks,
> Sam.
>