On Tue, May 1, 2012 at 10:12 AM, George Christman
<gchrist...@cardaddy.com> wrote:
> Hello Kalle, I've finally got this to work :) Our other developer ended up
> rewriting his code to be much friendlier to work with. Anyhow I have one
> last question, he's returning a list of roles to me which I need to populate
> SimpleAuthorizationInfo with. Could you explain how I would get the list of
> roles into the doGetAuthorization method?
Since I'm lazy, I'm just copying Les Hazlewood's response to a similar
question on a thread titled "Shiro and LDAP authentication" on
shiro-user list:
On Fri, Dec 16, 2011 at 11:20 AM, Les Hazlewood <lhazlew...@apache.org> wrote:
> On Dec 16, 2011, at 8:03 AM, seme wrote:
>
>> Here is my scenario, user gets authenticated via cas and has authorization
>> info in attributes from CAS ldap.
>> I want to take those attributes and build permissions for authorization, I
>> am trying to extend AuthorizingRealm, but I can't find away to pass those
>> attributes.
>> Also, I am using shiro for authorization only, when does
>> doGetAuthorizationInfo gets called?
>
> It is called the very first time that an authorization operation occurs (e.g.
> a permission or role check). If caching is enabled/configured, the
> AuthorizationInfo will be cached at that time to avoid further continuous
> 'hits' on the back-end data store.
>
> For Realms that lookup both authentication and authorization information, you
> could preemptively construct and cache an AuthorizationInfo object during
> authentication so there is only one perceived 'hit' during login. You would
> do this by calling the getAuthorizationInfo(PrincipalCollection principals)
> method from within your doGetAuthenticationInfo method.
>
So.. you'd enable authorizationcache (your roles aren't gonna change
after authentication right?), then stick your roles in
doGetAuthenticationInfo() into your authorization cache and call
getAuthorizationInfo() and verify that your doGetAuthorizationInfo()
is never called. Or alternatively, you could create a secondary
principal of your choice that carries the roles or put them in a
threadlocal or just redo your remote authentication in
doGetAuthorizationInfo() in case your roles may dynamically change
(but consider the performance implications).
Kalle
>
> this is my code used to set my custom token
>
> page.class
>
> //hri crowd authentication
> HRILoginClient client = new HRILoginClient();
> HRISubject authenticate = client.authenticate(username,
> password);
>
> //tapestry security authentication
> Subject currentUser = SecurityUtils.getSubject();
> HRIAuthenticationToken token = new
> HRIAuthenticationToken(authenticate.getUsername());
>
> //Need to pass these roles into EPRSRealm
> System.out.println("roles" + authenticate.getRoles());
>
> currentUser.login(token);
>
>
> AuthorizationInfo in EPRSRealm.class
>
> //Not sure how to pass roles into this method.
> protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
> principals) {
>
> Set<RoleNames> roleNames;
> return new SimpleAuthorizationInfo(roleNames);
> }
>
> Thanks Kalle.
>
>
>
>
> --
> View this message in context:
> http://tapestry.1045711.n5.nabble.com/tapestry-security-w-Remote-Login-tp5505792p5678498.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
