On Wed, Feb 22, 2012 at 11:50 AM, George Christman <gchrist...@cardaddy.com> wrote: > Hi Kalle, I apologize, I misspoke in my previous post. Our remote sso > doesn't serve as an authorization protocol, I meant to say it serves as a
Well, it's partly an authorization protocol if it returns you roles specific to the local application. > Authentication protocol. We are using web.xml filters to trigger > Authentication. Once the user has been authenticated, the service returns a > user Id and list of roles while populating the application session. Where I > need some help is getting the user info into the Authorization Manager. The > sso service was built custom by one of our in house developers, so would > tynamo-federatedaccounts still be a good candidate for this? Absolutely. Short cutting that, you could extend the ready-made filter, and call Subject.login after the original filter has already populated the session (I'd argue that it's doing too much, but that's semantics) and have a corresponding realm just for authorizing the sso users. Any solution for this you build would probably start looking more and more like federatedaccounts. You have to study the code a bit. The basic difference is that if you don't want your local application to participate in the remote authentication process in anyway (for example, if you don't have a need to ban individual users accessing your application), you can just have an authorizing realm and do there whatever else you need to do to transfer the role names from the session to your authorizationInfo. Kalle --------------------------------------------------------------------- To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
