shiro-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Les Hazlewood <>
Subject Re: Performance/Object creation issues
Date Thu, 17 Jan 2013 02:26:08 GMT
Hi John,

I'm curious - what performance overhead did you see?
 SimplePrincipalCollection is a simple wrapper around a
LinkedHashMap<String,Set> - was Map/Set construction slow? (I don't know
your application's performance threshold requirements, and I'm always
curious how to make things faster).

Also, yes, I'll echo Jared's advice - you just need to call
subject.login(authcToken) - no need to construct anything prior.  When you
turn on authentication caching, AuthenticationInfo instances (and their
internal PrincipalCollecition) are cached after creation and re-used while
they exist in cache.

Also know that Shiro defaults to storing authentication state
(isAuthenticated, PrincipalCollection) in the Subject's Session.  This is
however fully customizable and you can turn this off (for example, if
you're building a stateless application and/or framework).  See the
DefaultSubjectDAO JavaDoc for more information.

On Wed, Jan 16, 2013 at 1:44 PM, John Vines <> wrote:

> That seems a lot more performant. I guess all taht overhead of dealing
> with PrincipalCollections the principalled Subjects did it in. Thanks for
> your help.
> John
> On Wed, Jan 16, 2013 at 3:21 PM, Jared Bunting <
>> wrote:
>> So, if I understand correctly, you are embedding the principal into the
>> AuthenticationToken (in the API call), then getting it out, building up
>> a Subject with it, then authenticating on that subject?
>> My thought would be to do something like the following.
>> AuthenticationToken authTok = api.convertToAuthToken(thriftToken); //
>> this should be a very simple conversion...grabbing a field or two,
>> parsing a string
>> Subject subject = new Subject.Builder().buildSubject();
>> subject.login(authTok); // if this is successful, the subject will be
>> populated with the PrincipalCollection
>> Then, in your realm, you do that actual conversion from your
>> AuthenticationToken to your PrincipalCollection.  It is important to do
>> it here, because this is where authentication caching happens.
>> Does that make sense?  Does it address your issues at all?
>> HTH,
>> Jared
>> On Wed 16 Jan 2013 11:42:46 AM CST, John Vines wrote:
>> > In our application, we have an API call which takes in a thrift based
>> > token, transforms it into the appropriate type of AuthenticationToken,
>> > pulls the principal out of it and creates a SimplePrincipalCollection
>> > with it, and uses that to build a Subject. I then do
>> > subject.login(token) with that subject to authenticate. However, we
>> > noticed in testing that the object creation from this process is
>> > killing performance. I changed it to keep a Map of thrift token ->
>> > Subject, and then utilize isAuthenticated() which seems to have
>> > alleviated the issue.
>> >
>> > However, I'm a bit miffed at the original performance issues, since I
>> > had set up Authentication caching. Is there a better way to just
>> > authenticate given a token, or is my way the right way? Additionally,
>> > I feel that caching a token->Subject is redundant with the
>> > authentication caching, so I don't know if there are better practices
>> > in this case as well.
>> >
>> > Thanks
>> > John

View raw message