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 <[email protected]>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 > > >
