As long as you are clear that we cannot tie Knox to Shiro and that we can't require other providers to be aware of anything from Shiro. This is what will allow composability for the Authentication Provider SPI.
As the Shiro Provider SPIs mature, it will be possible for some deployments to use more and more of Shiro and require fewer others. We will not however restrict the use of other filter based providers. Shiro SPIs are for easy scenarios and lower level filter based providers are for the most flexibility and will require more work. Shiro Provider can represent the model for doing others. If you agree with all of that then we are in sync. On Fri, Sep 20, 2013 at 5:29 PM, Dilli Arumugam <[email protected]>wrote: > Good Larry. > I believe we are in sync. > As we integrate with some candidate custom/customer filters, we would > mature our Shiro Custom Realms and the code addition/change to be done by > customers would nil/minimal. > Thanks > Dilli > > > On Fri, Sep 20, 2013 at 2:04 PM, larry mccay <[email protected]> > wrote: > > > Hi Dilli - > > > > What you describe is exactly the sort of maturation that is required for > > the Shiro Provider SPI. It is all goodness and should be pursued. Like I > > said in my response the easy stuff needs to be made really easy and the > > Shiro Provider SPI is the best place to enable that. > > > > It does not have to be - nor should it be - mutually exclusive with > > Authentication Provider SPIs. > > > > We do need to keep the composability and the "standard java" integration > > stories too. > > > > thanks, > > > > --larry > > > > > > On Fri, Sep 20, 2013 at 4:50 PM, Dilli Arumugam > > <[email protected]>wrote: > > > > > 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. > > > > > > > -- > 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. >
