I've gone the caching route before, I populated the authZ cache directly from doGetAuthenticationInfo. (not the cleanest, but it worked).
Assuming you piggy back on the existing caching infra, I wouldn't worry about stale cache, it will be cleaned up on logout. You could also store extra info in the Principal object (in your case a list of roles, etc): http://shiro-user.582556.n2.nabble.com/How-to-set-a-custom-principal-object-td1090270.html On Tue, Jun 28, 2016 at 7:03 AM, Martin Nielsen <[email protected]> wrote: > Hello again! > > I have run into a new exciting challenge, concerning a realm i need to > build for authentication and authorization. > > Basically, i need create a realm, which performs both authN and authZ > against a rest service. The challenge is that there is no "superuser" > credentials i can use. So i will be performing authN/Z towards the service > with the users actual authentication token. > > So basically, the authorization will be performed by retrieving the > subjects own "User" object, via a REST service, using the users actual > username and password as authentication towards the REST service. > > The problem i have run into is that the two methods used for this are > discrete: > > @Override > protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection > principals) { > } > > @Override > protected AuthenticationInfo > doGetAuthenticationInfo(AuthenticationToken token) throws > AuthenticationException { > } > > During the call doGetAuthenticationInfo, i have the token as provided by > the user, so i can actually login. but during doGetAuthorizationInfo, i > only have the PrincipalCollection. Since i no longer have access to the > password, i can't contact the REST service again and get the rest of the > data. > > So my question is: What is the smartest way to handle this? > > The first idea, which i quickly skipped over, was to save the password > inside the PrincipalCollection, but that would be terrible. > Another idea i had was to pull out both authentication and authorization > data on the authN action, and then cache it for the authZ action. But that > does seem like it might return stale data in some cases. > > > Do you guys have any sleeker ways of handling the issue, maybe even > firsthand experience? > > Thanks in advance > > -Martin >
