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
