Yes, you understand. You have to go back to my original response and understand the different categories of security developers. Which already includes requirements from customers.
This is also a common model for such things. Weblogic has pluggable providers out of the box that you can configure and extend as well as a model for developing custom providers. On Fri, Sep 20, 2013 at 7:42 PM, Dilli Arumugam <[email protected]>wrote: > 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. >
