RE: [Acegisecurity-developer] Suggested approach for authority design
Ray,
Many thanks for writing in. You've pretty much confirmed many of the things I
was thinking. I just wanted to be sure that I was going down the path of least
resistance and not run across some DOH! Moment a month later when I realize
there's a far better way to do it.
I think what I'll do is create a custom AuthorityProvider that will do the jaas
operations and the role creation I need, since there are other stuff I should
be pulling in as well that are not coming from JAAS, and using an
AuthorityGranter doesn’t sit well with me.
Thanks again for your input. Appreciate it much.
-tim
-Original Message-
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Ray Krueger
Sent: Monday, July 18, 2005 11:44 PM
To: acegisecurity-developer@lists.sourceforge.net
Subject: Re: [Acegisecurity-developer] Suggested approach for authority design
Hey Tim, Jaas is full of smells :P
Let's see if I can help you out here...
1. You are correct. You can chain AuthenticationProviders, but as soon
as one returns a valid token the chain ends.
2. The first part of this is what the AuthorityGranter interface is
designed for. The AuthenticationDao thing, I'm not sure what your
intent was. Either way, the AuthenticationDao.authenticate(...) method
returns a UserDetails instance, which has the GrantedAuthority[]
getAuthorites() method on it.
3. The AuthorityGranter (AuthorityResolver would have been a better
name though hehe) returns a set for exactly the reason you mentioned.
You pass it a principal and it returns a set of ROLE_names. This +
some jdbc access or whatever your authority source is going to be
would be an option. Inelegance is in the eye of the beholder :P
One thing to keep in mind with Jaas, there will (almost) always be at
least one principal to work with, and that's the user. So if certain
users are going to get extra roles or authorities based on their
username for example writing an AuthorityGranter to do that would be
the way to go.
I hope this helps, or at least made sense.
-Ray
On 7/18/05, Tim Kettering [EMAIL PROTECTED] wrote:
Hi everyone,
On this project I'm working on, we are using JAAS to authenticate a token,
and Acegi's JAAS support classes allow for the translation of the user and
its principals to Acegi's authority objects. But in this particular case,
we are not interested in the principals that JAAS returns. We want to
continue using our own method for obtaining the authorities.
So I've been looking at a few possible approaches. But none of them seem to
really avoid the sense of code smell, so I thought I'd ask on the list for
suggestions from people who may be more familiar with a better strategy.
using a different authentication provider to simply populate the authorities
– it seems to me that authentication manager will only process with one
authentication provider, and if it returns a valid token, it does not
continue down the list… so when jaas authentication provider returns a valid
token, it wont process the custom class I made. (correct me if im wrong).
Replace Acegi's JaasAuthenticationProvider with a similar one of our own
that adds a method that obtains the additional authorities and adds it in.
This was the approach I started with, and I thought perhaps I could make use
of the AuthenticationDao to obtain the authorities I needed for the user and
add them in, but apparently AuthenticationDao does not provide an easy way
to simply obtain the authorities.. but instead, need to obtain the user
itself.
With the latest code in HEAD, AuthorityResolver can now return a set, so I
could hack a custom Resolver that ignored the returned Jaas Principal and
simply provided its own, but this seems rather inelegant, and has it's own
issues.
So, I guess I'm asking here.. is there a easier way (that I've missed) to
introduce my own GrantedAuthorities in the JAAS authentication flow??
Thanks in advance!
-tim
HS^µéšŠX¬²š'²ŠÞu¼ƒŠÇ(½êÄjÌ‹Š{±2(+jب+kj×
‰ë®‰ˆÁbÛš™^¶‡è–Z0F†™ªl²ÚÚŠm~Šðj·Z®Øœ•ëú+™«b½åžmƬ¶Æ§vj+xgz÷«ÊØbž
¨ºwžvÚ zÛ©¶‹)yç_jËa¶Úý§l¢Çgr‰¿iؾ;í©e¡È^¸÷j)ÉbrAè™èm¶ŸÿiÇ [EMAIL
PROTECTED]±ç.®+ruëÞ–Š^®f¢–)à–+-Ç
ŠÇœº¸ÉׯzZ)z¹b²Û,¢êÜyú+éÞ¶m¦Ïÿ–+-²Ê.ÇŸ¢¸ ë–+-³ùb²Ø§~Úqè±ç.®+ruëÞ–Š^
---
SF.Net email is sponsored by: Discover Easy Linux Migration Strategies
from IBM. Find simple to follow Roadmaps, straightforward articles,
informative Webcasts and more! Get everything you need to get up to
speed, fast. http://ads.osdn.com/?ad_idt77alloc_id492op=click
___
Home: http://acegisecurity.sourceforge.net
Acegisecurity-developer mailing list
Acegisecurity-developer@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
[Acegisecurity-developer] Suggested approach for authority design
Hi everyone, On this project Im working on, we are using JAAS to authenticate a token, and Acegis JAAS support classes allow for the translation of the user and its principals to Acegis authority objects. But in this particular case, we are not interested in the principals that JAAS returns. We want to continue using our own method for obtaining the authorities. So Ive been looking at a few possible approaches. But none of them seem to really avoid the sense of code smell, so I thought Id ask on the list for suggestions from people who may be more familiar with a better strategy. using a different authentication provider to simply populate the authorities it seems to me that authentication manager will only process with one authentication provider, and if it returns a valid token, it does not continue down the list so when jaas authentication provider returns a valid token, it wont process the custom class I made. (correct me if im wrong). Replace Acegis JaasAuthenticationProvider with a similar one of our own that adds a method that obtains the additional authorities and adds it in. This was the approach I started with, and I thought perhaps I could make use of the AuthenticationDao to obtain the authorities I needed for the user and add them in, but apparently AuthenticationDao does not provide an easy way to simply obtain the authorities.. but instead, need to obtain the user itself. With the latest code in HEAD, AuthorityResolver can now return a set, so I could hack a custom Resolver that ignored the returned Jaas Principal and simply provided its own, but this seems rather inelegant, and has its own issues. So, I guess Im asking here.. is there a easier way (that Ive missed) to introduce my own GrantedAuthorities in the JAAS authentication flow?? Thanks in advance! -tim
Re: [Acegisecurity-developer] Suggested approach for authority design
Hey Tim, Jaas is full of smells :P
Let's see if I can help you out here...
1. You are correct. You can chain AuthenticationProviders, but as soon
as one returns a valid token the chain ends.
2. The first part of this is what the AuthorityGranter interface is
designed for. The AuthenticationDao thing, I'm not sure what your
intent was. Either way, the AuthenticationDao.authenticate(...) method
returns a UserDetails instance, which has the GrantedAuthority[]
getAuthorites() method on it.
3. The AuthorityGranter (AuthorityResolver would have been a better
name though hehe) returns a set for exactly the reason you mentioned.
You pass it a principal and it returns a set of ROLE_names. This +
some jdbc access or whatever your authority source is going to be
would be an option. Inelegance is in the eye of the beholder :P
One thing to keep in mind with Jaas, there will (almost) always be at
least one principal to work with, and that's the user. So if certain
users are going to get extra roles or authorities based on their
username for example writing an AuthorityGranter to do that would be
the way to go.
I hope this helps, or at least made sense.
-Ray
On 7/18/05, Tim Kettering [EMAIL PROTECTED] wrote:
Hi everyone,
On this project I'm working on, we are using JAAS to authenticate a token,
and Acegi's JAAS support classes allow for the translation of the user and
its principals to Acegi's authority objects. But in this particular case,
we are not interested in the principals that JAAS returns. We want to
continue using our own method for obtaining the authorities.
So I've been looking at a few possible approaches. But none of them seem to
really avoid the sense of code smell, so I thought I'd ask on the list for
suggestions from people who may be more familiar with a better strategy.
using a different authentication provider to simply populate the authorities
– it seems to me that authentication manager will only process with one
authentication provider, and if it returns a valid token, it does not
continue down the list… so when jaas authentication provider returns a valid
token, it wont process the custom class I made. (correct me if im wrong).
Replace Acegi's JaasAuthenticationProvider with a similar one of our own
that adds a method that obtains the additional authorities and adds it in.
This was the approach I started with, and I thought perhaps I could make use
of the AuthenticationDao to obtain the authorities I needed for the user and
add them in, but apparently AuthenticationDao does not provide an easy way
to simply obtain the authorities.. but instead, need to obtain the user
itself.
With the latest code in HEAD, AuthorityResolver can now return a set, so I
could hack a custom Resolver that ignored the returned Jaas Principal and
simply provided its own, but this seems rather inelegant, and has it's own
issues.
So, I guess I'm asking here.. is there a easier way (that I've missed) to
introduce my own GrantedAuthorities in the JAAS authentication flow??
Thanks in advance!
-tim
HS^µéšŠX¬²š'²ŠÞu¼ƒŠÇ(½êÄjÌ‹Š{±2(+jب�+kj× ‰ë ®‰ˆÁb�Ûš™^¶‡è–Z0F†�™ªl²ÚÚŠm~Šðj·Z®Øœ•ë�ú+™«b½åžmƬ¶Æ§vj+xgz÷«ÊØbž
¨ºwžvÚ zÛ©¶‹)yç_jËa¶Úý§l¢Çgr‰¿iØ�
