There would also be use cases where we may have to do something like this Customer Filter -> ShiroFilter -> ShiroRelam
If a customer filter asserts the authenticated identity as a http request attribute or http header, this would work nicely. In this case, we do not touch customer filter but add logic in a shiro realm to understand the request attribute coming from customer filter and provides right authentication result. Shiro then creates the right Shiro subject which gets used in Knox layers. Either way, we add Knox logic for authentication in Shiro Realm (or a custom Shiro Filter). Thanks Dilli Dorai On Fri, Sep 20, 2013 at 1:23 PM, Dilli Arumugam <[email protected]>wrote: > Larry, Kevin, > > I doubt whether you could take a bunch of customer authentication filters > as it is and make them work with Knox without any adapter. Each one of > them could have a different way of propagating authentication assertion, > each one could have a different idea of session management. So, I think you > would need some adaptation code for each of customer filter somewhere so > they can integrate nicely with Knox. Given that, I think, we add code to > adapt them as Shiro realm and plug them in to Shiro. > > Knox -> Shiro -> Shiro Custom Realm(One for each authentication type*) > > *Potential authentication types: > > LDAP > JDBC > AD > File > CAS > (All the above are supported out of box in Shiro.) > > PIngID > SAML > ... > > As you have already quoted, Shiro not only provides authentication modules > and framework, but also authorization framework and modules. As we have > already pull in Shiro in Knox, I think we should leverage as much as > possible. > > Thanks > Dilli > > > On Fri, Sep 20, 2013 at 1:03 PM, larry mccay <[email protected]> wrote: > >> All - >> >> This discussion topic is actually from Kevin and we decided that it should >> be restarted on the public list. >> >> Community insight is important for these sorts of discussions. >> >> The basic question being raised is should we be using Shiro more >> fundamentally as our SPI model for various security capabilities. The >> path >> I set us on initially was to use Shiro only for authentication. At the >> time I didn't want to deal with LDAP based authentication and wasn't >> thinking much beyond that. I tried both Shiro and Spring Security for >> this >> and liked Shiro better. >> >> Anyway, there are two basic camps: >> >> *"Shiro already **supports** that** so why reinvent the wheel"* >> It looks like Shiro has SPIs for most of the major security concerns: >> authentication, authorization, group/principal mapping, authentication >> optimization (e.g. session and encrypted cookies) >> >> *"With filters customers can bring their own filter and mix and match*" >> Customers seem to really like the story about being able to use their own >> filters. Lets say some customer has a SiteMinder filter that they want to >> use in Knox for authentication. If they plug that into Knox for ATN >> instead of Shiro, anything other functionality (e.g. ATZ) that Shiro would >> have provided will be lost. If Knox had an ATZ filter instead of using >> Shiro this wouldn't be the case. >> >> I'm looking forward to the discussion. >> >> --larry doAs(kevin) >> > > -- CONFIDENTIALITY NOTICE NOTICE: This message is intended for the use of the individual or entity to which it is addressed and may contain information that is confidential, privileged and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient, you are hereby notified that any printing, copying, dissemination, distribution, disclosure or forwarding of this communication is strictly prohibited. If you have received this communication in error, please contact the sender immediately and delete it from your system. Thank You.
