I actually misspoke about Tapestry - it is a web app framework but it has a pluggable architecture so that one can use Shiro, Spring or others.
On Fri, Sep 20, 2013 at 7:54 PM, larry mccay <[email protected]> wrote: > 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. >> > >
