Yeah - I think the mixup was largely on the user of the word
"credential" We use that word to mean the "secret" information used
during authentication, such as a password or private key. In this
case, in the JSecurity parlance I would probably store the token as a
"principal" via the CrowdRealm.
I agree that checking the validity of a token is a common security
pattern, especially for SSO setups. I also like the idea of providing
some easy hook or way to do this in the JSecurity core. It seems to
me that this should somehow fit in as a custom CrowdFilter that is
plugged into the JSecurityFilter and has the ability to route the user
to a login URL if the token is no longer valid - or perhaps to simply
expire the users session if the token is invalid, thus letting a later
filter route the user to the login URL based on the invalid (and now
unauthenticated) session.
Jeremy
On Nov 24, 2008, at 10:10 AM, Alan D. Cabrera wrote:
Crowd calls its a token I would probably call it a ticket. There's
a method in the Crowd API that you can call to make sure the ticket
is still good. The ticket is a handle to a "login session" at the
Crowd server. You can invalidate that session using the Crowd
console to the Crowd server and, so, that the next time you check to
see if the ticket is still good the Crowd API will say "no". So,
you can have a filter that checks the token/ticket for every page
hit/call or after a certain period expires, say 5 minutes.
This is a fairly common security pattern; at least one that I've run
into on a regular basis. I think we should include it in JSecurity
proper instead of forcing people to make ad hoc solutions; not that
JSecurity doesn't provide adequate methods to do so.
Regards,
Alan
On Nov 24, 2008, at 5:51 AM, Les Hazlewood wrote:
Hi Alan,
This is cool - I like seeing new realms :)
What do you mean exactly when you say "one can invalidate the token
session from the Crowd console". What is a 'token session'?
It sounds as if this token would be a principal - an identifying
attribute of the current user. A credential, strictly speaking, is
something that verifies a user identity by matching a known value.
Is
the token really a credential?
Or perhaps it is just something attributed to the current user - not
an identifying attribute like a username or SSN - I dunno. If that
is
the case, there's nothing wrong with just sticking it in the session
either (Subject.getSession()). The only benefit of including it as a
principal in the PrincipalCollection is that would be serialized as a
cookie if cookies are enabled, thereby not using a session at all
(can
be a good thing depending on architecture, as I'm sure you know).
In any case, I think checking it on a regular basis to make sure it
is
still valid is a behavior specific to Crowd, not JSecurity, so I
think
it makes sense to do this checking in a filter. If it extends one of
the JSecurity Filter classes, then you can do anything they can do,
like redirect to the login page, etc.
HTH,
Les
On Sun, Nov 23, 2008 at 4:00 PM, Alan D. Cabrera <[EMAIL PROTECTED]
> wrote:
So, I've checked in my first crack at a crowd based realm. I have
a few
questions.
As you may have noticed, I used enums to direct the behavior of
the realm.
It's not sure to me that this will work within the framework as it
now
stands.
When you log into Crowd you get a token. This token can be
checked on a
regular basis to make sure that it's still valid; one can
invalidate the
token session from the Crowd console. It's not clear to me where
I can
place this check in JSecurity. I'm thinking that I'll need to
write my own
filter that gets the Subject and obtains the credentials object
that I
returned during authentication. In this credential is the token
and I can
use that to check the validity of it.
Thoughts?
Regards,
Alan
