Larry,. If I understand you right, you want to have the option of having Knox without any Shiro dependency. My plan was to always have Shiro compile time and runtime dependency in Knox. Thanks Dilli
On Fri, Sep 20, 2013 at 4:34 PM, larry mccay <[email protected]> wrote: > 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. > > > -- 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.
