We need to be able to plugin authorization providers that have nothing to do with Shiro. We need to be able to have customers contribute a Spring Security provider that has nothing to do with Shiro. It can't be required to always be there and its internals can't leak into the contracts of the request processing.
We *should* mature the Shiro provider so that customers choose to use it for everything that we enable it to do. That may mean that they need no other security in that particular deployment choice. My proposal has Shiro as the preferred way to integrate things and the way for us to make certain things very easy but not the only model. Shiro in my opinion is a very good framework but it still isn't as popular as Spring Security and it lacks the "standard java" story. Our Shiro provider will be great to help folks get things done easily but we will enable them to get closer to bare metal at the filter provider level. On Fri, Sep 20, 2013 at 7:25 PM, Dilli Arumugam <[email protected]>wrote: > Larry, > > In my proposal Knox is tied to Shiro framework at the bottom. > Shiro is below Knox. > However, filters sitting on top of Knox need not be aware of Shiro. > In other words, Shiro would be in the stack all the time and would be seen > by Knox but not normal customer code or filters. > Customer have the choice to get to know Shiro and write plugins for Shiro. > > Does it sound reasonable to you? > Thanks > Dilli > > > > > > > On Fri, Sep 20, 2013 at 3:57 PM, larry mccay <[email protected]> > wrote: > > > 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. > > > > > > > -- > 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. >
