jasig-cas IRC Logs-2011-09-07

Owned by Apereo Infrastructure
Last updated: Sept 07, 2011Version comment
6 min read

[11:08:55 CDT(-0500)] <pacman__> hello
[11:09:08 CDT(-0500)] <serac> howdy
[11:09:44 CDT(-0500)] <pacman__> iwas hesitating if it would be faster to solve some questions about CAS
[11:09:54 CDT(-0500)] <serac> We'll see (smile)
[11:10:03 CDT(-0500)] <pacman__> with the IRC instead of the mailing list that its a bit more formal
[11:10:06 CDT(-0500)] <serac> The mailing lists are typically fairly expedient.
[11:10:06 CDT(-0500)] <pacman__> great (smile)
[11:10:54 CDT(-0500)] <pacman__> if you consider this questions should go to the mailing list please tell me and i will post them
[11:10:58 CDT(-0500)] <pacman__> ok
[11:11:08 CDT(-0500)] <pacman__> so i would want to know if its possible to
[11:11:19 CDT(-0500)] <pacman__> make some actions
[11:11:26 CDT(-0500)] <pacman__> when a user signs out
[11:11:54 CDT(-0500)] <serac> What kind of actions?
[11:11:55 CDT(-0500)] <pacman__> the same way its possible to make them whem the user signs on in the authentication handler
[11:12:10 CDT(-0500)] <pacman__> well i would want to count the number of active sessions
[11:12:18 CDT(-0500)] <pacman__> a username has
[11:12:33 CDT(-0500)] <pacman__> so i was thinking to use a DB counter
[11:12:38 CDT(-0500)] <serac> Don't need to.
[11:12:51 CDT(-0500)] <pacman__> that its incremented when the credentials are ok and the user logs in
[11:12:59 CDT(-0500)] <pacman__> and cerement it when the user logs out
[11:12:59 CDT(-0500)] <serac> You have a ticket.
[11:13:33 CDT(-0500)] <serac> All tickets are in ticket registry, so if you used JpaTicketRegistry for example a simple query could provide a fast answer.
[11:13:39 CDT(-0500)] <pacman__> so how cam i check the number of active sessions a user id has programatically?!
[11:13:55 CDT(-0500)] <pacman__> ok i understand
[11:14:13 CDT(-0500)] <serac> Find all the tickets where the Authentication().getPrincipal().getName() equals that of logged out user.
[11:14:31 CDT(-0500)] <serac> Should ask important question:
[11:14:39 CDT(-0500)] <serac> I'm thinking user has multiple CAS SSO sessions.
[11:14:42 CDT(-0500)] <serac> Is that what you mean?
[11:14:52 CDT(-0500)] <serac> I am not talking about servlet session.
[11:14:55 CDT(-0500)] <pacman__> yes
[11:15:06 CDT(-0500)] <pacman__> SSO sessions
[11:15:09 CDT(-0500)] <serac> Why do you want to allow multiple SSO sessions in the first place?
[11:15:35 CDT(-0500)] <pacman__> no wait
[11:15:42 CDT(-0500)] <pacman__> i want that
[11:15:57 CDT(-0500)] <pacman__> if a user gives his user/ password to other people
[11:16:12 CDT(-0500)] <serac> Want what? Need to clarify.
[11:16:13 CDT(-0500)] <pacman__> only a maximum number of sessions are available
[11:16:25 CDT(-0500)] <serac> Huh?
[11:16:42 CDT(-0500)] <serac> Maximum? What resource is limited or doing the limiting here?
[11:17:15 CDT(-0500)] <pacman__> the number of active sessions logged in
[11:17:35 CDT(-0500)] <pacman__> something like
[11:17:59 CDT(-0500)] <pacman__> with this credentials there are 3 active sessions
[11:18:18 CDT(-0500)] <serac> Credentials are never stored in a durable manner.
[11:18:22 CDT(-0500)] <serac> Only the resolved principal.
[11:18:30 CDT(-0500)] <serac> Although typically the principal matches the authenticated username.
[11:18:36 CDT(-0500)] <serac> (or some simple transformation thereof)
[11:19:09 CDT(-0500)] <pacman__> but i can check how many active tickets are there for a specific principal
[11:19:12 CDT(-0500)] <pacman__> ?
[11:19:36 CDT(-0500)] <serac> It's possible in general, but is infeasible for some implementations of TicketRegistry.
[11:20:32 CDT(-0500)] <serac> I'd strongly recommend JpaTicketRegistry for your use case.
[11:20:54 CDT(-0500)] <pacman__> Ok sounds good
[11:20:57 CDT(-0500)] <pacman__> this way
[11:21:09 CDT(-0500)] <serac> You should consider preventing dupe sessions in the first place.
[11:21:09 CDT(-0500)] <pacman__> it is possible to implement a feature similar
[11:21:30 CDT(-0500)] <pacman__> what are dupe sessions?
[11:21:36 CDT(-0500)] <serac> I'd think you'd give better use feedback on the front end by preventing auth if same person is already authenticated.
[11:22:11 CDT(-0500)] <serac> So prevent authentication if there's an existing SSO session whose principal matches username.
[11:22:55 CDT(-0500)] <serac> Honestly I think both approaches are significant work for relatively little return.
[11:23:10 CDT(-0500)] <serac> You should have better audit mechanisms than this for detecting abuse.
[11:23:25 CDT(-0500)] <pacman__> well i was thinking of allowing to share some accounts
[11:23:30 CDT(-0500)] <pacman__> but in a limited way
[11:23:49 CDT(-0500)] <pacman__> that's why i was thinking of this
[11:23:56 CDT(-0500)] <serac> I've never heard of a sound or sane use case for credential sharing.
[11:24:04 CDT(-0500)] <pacman__> i think i'll give JpaTicketRegistry
[11:24:08 CDT(-0500)] <serac> Shoot, I don't even do it at home.
[11:24:15 CDT(-0500)] <pacman__> (smile)
[11:24:24 CDT(-0500)] <serac> Should be fairly easy.
[11:24:46 CDT(-0500)] <serac> Just customize the LogoutController model data with results of your query and then customize the view to display it.
[11:24:49 CDT(-0500)] <serac> Voila.
[11:25:35 CDT(-0500)] <pacman__> great, i was doing that but i thought that maybe there was a sign out handler or something like that
[11:25:58 CDT(-0500)] <pacman__> may i ask you another question?
[11:26:39 CDT(-0500)] <pacman__> (may be its a strange thing like the one before (smile)
[11:26:42 CDT(-0500)] <pacman__> )
[11:26:56 CDT(-0500)] <serac> Sure – I'm here all day (wink)
[11:28:12 CDT(-0500)] <pacman__> do you know if its possible in the AuthenticationHandler to know the URL that has been requested by the user before the login page shows
[11:28:14 CDT(-0500)] <pacman__> ?
[11:28:27 CDT(-0500)] <serac> You mean the service URL?
[11:28:30 CDT(-0500)] <pacman__> yes
[11:29:05 CDT(-0500)] <serac> Only a Credential is given to AH.
[11:29:08 CDT(-0500)] <serac> But...
[11:29:40 CDT(-0500)] <serac> you could create a custom Credential type that extends, for example. UsernamePasswordCredentials that has an additional param containing service, if present.
[11:30:16 CDT(-0500)] <serac> Another likely easier method is to create a ThreadLocal container for service, store it somewhere up the stack, then access it down stream inside the AH>
[11:30:18 CDT(-0500)] <serac> AH.
[11:30:31 CDT(-0500)] <pacman__> oks i see
[11:30:38 CDT(-0500)] <pacman__> for the first option
[11:31:01 CDT(-0500)] <serac> There's an existing Webflow action for obtaining service in login-webflow.xml, so you should consider extending that.
[11:31:05 CDT(-0500)] <pacman__> i would need to overrride the principaltocredentials resolver right?
[11:31:27 CDT(-0500)] <serac> I honestly think you'll touch fewer components with a ThreadLocal impl.
[11:31:44 CDT(-0500)] <serac> Store the service in the login Webflow action.
[11:31:57 CDT(-0500)] <serac> Retrieve it later in the AH.
[11:32:03 CDT(-0500)] <pacman__> oks
[11:32:40 CDT(-0500)] <pacman__> sounds like an easy hack
[11:32:51 CDT(-0500)] <serac> Straightforward anyway.
[11:49:12 CDT(-0500)] <apetro> multiple active SSO sessions are pretty common for power users
[11:49:18 CDT(-0500)] <apetro> might have a CAS SSO session for each device
[11:49:25 CDT(-0500)] <apetro> might have multiple browsers per device
[11:49:43 CDT(-0500)] <serac> Good point.
[11:50:19 CDT(-0500)] <apetro> seems like the available wins here are user experience (can you tell me, the user, something interesting about my recent or concurrent sessions that might allow me to realize my account is being abused, without needlessly panicking me?)
[11:50:56 CDT(-0500)] <apetro> and heuristics around abuse (if I'm logged in from two different geographies too close together, that's probably abuse. Add massive amount of pain around geolocation, and what happens if I VPN, here.)
[11:51:52 CDT(-0500)] <serac> Again, I think the value for abuse prevention is negligible.
[11:51:58 CDT(-0500)] <apetro> that was too close in time, too disparate in location.
[11:52:25 CDT(-0500)] <apetro> yeah. I think all the value is in UX for informing the user to allow them to self-monitor.
[11:52:35 CDT(-0500)] <serac> yup
[11:54:42 CDT(-0500)] <apetro> ("You already have active SSO sessions that started at these times from these IP addresses? Not you? Click here to terminate them all. Click here to contact your support provider. Click here to hire a web developer to invent something better than 'click here', which is apparently some kind of 'worst practice'. Etc.")
[11:54:55 CDT(-0500)] <serac> haha
[11:55:20 CDT(-0500)] <serac> The "terminate them all" capability sounds interesting.
[11:59:30 CDT(-0500)] <apetro> quite
[12:00:06 CDT(-0500)] <apetro> but I'm interested that this gets back to adding some capabilities to the ticket registry API that, as you've noted elsewhere, may be problematic to implement efficiently for all ticket registry implementations.
[12:00:26 CDT(-0500)] <pacman__> yes apetro those are the features i would want to implement in the feature
[12:01:13 CDT(-0500)] <apetro> some kind of tension between functionality, ease of implementation, and performance. Tension that probably needs to be resolved guided by some handy use cases. Terminate all sessions for this user is a really interesting use case, it's the first immediate response I'd want if I thought an account was compromised.
[12:01:37 CDT(-0500)] <apetro> and presumably any reasonable implementation of it would log what sessions were terminated, setting up the next level reasonable response to that use case – chasing down where these sessions came from.