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_idt77&alloc_id492&op=click _______________________________________________ Home: http://acegisecurity.sourceforge.net Acegisecurity-developer mailing list Acegisecurity-developer@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/acegisecurity-developer
