Building a realm to perform pass-through authN/Z

[Martin Nielsen <mn...@gmail.com>]

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

Re: Building a realm to perform pass-through authN/Z

[Brian Demers <br...@gmail.com>]

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 <mn...@gmail.com> 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
>