You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@shiro.apache.org by Les Hazlewood <lh...@apache.org> on 2008/12/16 15:22:26 UTC
Re: Atlassian Crowd based realm
I'm slowly catching up on emails, so please forgive the delay ;)
I'm not quite sure of the usage patterns of Crowd and its token checking,
but a clean solution might depend on the architecture.
For example, if Crowd is anything like JSecurity, the 'token' is sent over
the wire attached to each RPC call and/or web request. It is then checked
on the server-side for validity. If not valid, it throws a specific
exception indicating why it failed, preventing the invocation/request/etc.
A more performant mechansim would probably be, on the client side (I'm
calling the CrowdRealm the 'client side' and the Crowd Server the 'server
side' in this example), to just send the token across the wire each time in
conjunction with the intended request, without checking its validity first.
Then the filter or method interceptor on the client side would check for an
specific exception thrown by the server side related to token invalidity and
then show the user something that explains why the request/invocation failed
(e.g. redirect to a nice page or show a popup dialog, etc).
You'd have to show this information anyway if you proactively checked the
token. Why go through the 'hit' of checking token validity before an
invocation starts when that valididty will be checked by the server anyway?
Seems like one more round-trip hop that can be avoided.
Of course, this assumes that checking validity requires a server-side call.
If not, that proactive checking might be viable, but I don't know how Crowd
works...
On Mon, Nov 24, 2008 at 2:08 PM, Jeremy Haile <jh...@fastmail.fm> wrote:
> 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 <li...@toolazydogs.com>
>>> 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
>>>>
>>>>
>>>>
>>>>
>>>
>>
>
Re: Atlassian Crowd based realm
Posted by David O'Flynn <do...@atlassian.com>.
On 03/01/2009, at 4:04 AM, Alan D. Cabrera wrote:
>
> On Jan 1, 2009, at 2:49 PM, daveoflynn wrote:
>> The ASF is entitled to free
>> copies of all our apps, but if you have any difficulties getting
>> license
>> keys etc, please shout.
>
> Thanks Dave. You wouldn't happen to know where I can get a hold of
> these keys?
It looks like the ASF haven't asked for Crowd licenses before, so if
you go to http://www.atlassian.com/opensource/ and apply for one,
we'll get it to you right away.
Re: Atlassian Crowd based realm
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Jan 1, 2009, at 2:49 PM, daveoflynn wrote:
>
>> One simple solution is to have
>> the peer do a security check w/ the Crowd server for
>> every call it receives; obviously a resource intensive solution.
>> A different solution would be to have the peer check after
>> some period, say five minutes. This could be an acceptable
>> compromise.
>
> Hi folks,
>
> This is exactly how Crowd integration works for other Atlassian
> applications. The crowd.properties file has a property named
> "session.validationinterval" which determines how often the client
> application (Confluence, JIRA, etc) should check with Crowd. If set
> to zero,
> the client app checks on every request.
>
> So, I think it's fair to say you're on the right track :-)
>
> I'm the Crowd Team Lead, so if you have any questions about how
> integration
> should work, please let me know, on or off list. The ASF is entitled
> to free
> copies of all our apps, but if you have any difficulties getting
> license
> keys etc, please shout.
Thanks Dave. You wouldn't happen to know where I can get a hold of
these keys?
Regards,
Alan
Re: Atlassian Crowd based realm
Posted by daveoflynn <do...@atlassian.com>.
> One simple solution is to have
> the peer do a security check w/ the Crowd server for
> every call it receives; obviously a resource intensive solution.
> A different solution would be to have the peer check after
> some period, say five minutes. This could be an acceptable
> compromise.
Hi folks,
This is exactly how Crowd integration works for other Atlassian
applications. The crowd.properties file has a property named
"session.validationinterval" which determines how often the client
application (Confluence, JIRA, etc) should check with Crowd. If set to zero,
the client app checks on every request.
So, I think it's fair to say you're on the right track :-)
I'm the Crowd Team Lead, so if you have any questions about how integration
should work, please let me know, on or off list. The ASF is entitled to free
copies of all our apps, but if you have any difficulties getting license
keys etc, please shout.
Regards,
Dave.
--
View this message in context: http://n2.nabble.com/Atlassian-Crowd-based-realm-tp1569667p2100030.html
Sent from the JSecurity Developer mailing list archive at Nabble.com.
Re: Atlassian Crowd based realm
Posted by "Alan D. Cabrera" <li...@toolazydogs.com>.
On Dec 16, 2008, at 6:22 AM, Les Hazlewood wrote:
> I'm slowly catching up on emails, so please forgive the delay ;)
Heh heh, please forgive my delay. :)
> I'm not quite sure of the usage patterns of Crowd and its token
> checking,
> but a clean solution might depend on the architecture.
>
> For example, if Crowd is anything like JSecurity, the 'token' is
> sent over
> the wire attached to each RPC call and/or web request. It is then
> checked
> on the server-side for validity. If not valid, it throws a specific
> exception indicating why it failed, preventing the invocation/
> request/etc.
>
> A more performant mechansim would probably be, on the client side (I'm
> calling the CrowdRealm the 'client side' and the Crowd Server the
> 'server
> side' in this example), to just send the token across the wire each
> time in
> conjunction with the intended request, without checking its validity
> first.
>
> Then the filter or method interceptor on the client side would check
> for an
> specific exception thrown by the server side related to token
> invalidity and
> then show the user something that explains why the request/
> invocation failed
> (e.g. redirect to a nice page or show a popup dialog, etc).
>
> You'd have to show this information anyway if you proactively
> checked the
> token. Why go through the 'hit' of checking token validity before an
> invocation starts when that valididty will be checked by the server
> anyway?
> Seems like one more round-trip hop that can be avoided.
>
> Of course, this assumes that checking validity requires a server-
> side call.
> If not, that proactive checking might be viable, but I don't know
> how Crowd
> works...
Your initial thoughts are along the same lines as mine. The validity
of the ticket is tested by a peer on first arrival. This test
involves communication with the Crowd server and can be considered
heavy weight. Usually peers will cache the result of the security
check so that they will not have to subsequently check the ticket with
the Crowd server.
Now, the Crowd server has a mechanism where a ticket can be
invalidated. Let's say a Wall Street trader has been let go and his
privileges have to be removed immediately rather than wait until all
his tickets expire. Any subsequent security checks against the Crowd
server will fail. But remember that a peer may be caching the initial
security check results. What to do? One simple solution is to have
the peer do a security check w/ the Crowd server for every call it
receives; obviously a resource intensive solution. A different
solution would be to have the peer check after some period, say five
minutes. This could be an acceptable compromise.
Jeremy's idea of using a CrowdFilter that would have its security
check period configurable sounds like the way to go.
Hope this explains my current thinking.
Regards,
Alan
> On Mon, Nov 24, 2008 at 2:08 PM, Jeremy Haile <jh...@fastmail.fm>
> wrote:
>
>> 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 <list@toolazydogs.com
>>>> >
>>>> 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
>>>>>
>>>>>
>>>>>
>>>>>
>>>>
>>>
>>