So.... here is how I think about the usecases that we need to support and
how the composability of our providers facilitate it.
The developers that we are empowering consist of at least the following
three categories:
1. Java Platform Security purists (at my core I fall into this category)
- I have had discussions with at least one major customer that feels
strongly that we should support JASPIC authentication modules
- I have also been involved with customer discussions where the
simplicity and openness of the Servlet Filter plugin model quelled the
concerns about integration immediately
2. Filter based security aficionados (usually at odds with Java Platform
Security purists :) )
- there are many existing servlet filter based authentication filters
from vendors and enterprise developers for both commercial, opensource and
proprietary user stores
- this is also the mechanism that enables the development of security
frameworks such as Shiro and Spring Security
3. Dedicated Security Framework consumers
- Shiro and Spring Security both enjoy large consumer bases
- Tapestry is a framework for frameworks to avoid lockin
- we would have a difficult time selling a Shiro only SPI model into a
Spring Security shop - especially those that have already invested in
extending Spring Security
Now, the usecases that we need to support for all of these developer
categories are:
* first and foremost, an easy integration model
* the ability to leverage existing investments relative to their category
as described above
* the ability to find, extend off-the-shelf plugins
* the ability to compose a provider chain that can mix and match
authentication, authorization, auditing from different sources
Easy things need to be as easy as possible more difficult things need to be
possible but can be more difficult to do.
I believe that all of this is possible with the following approach:
Shiro Provider SPI: This is our OOTB provider and our preferred plugin
programming model (or at least can be once we mature the plugin). This is
where easy things are made very easy. We know how to leverage the results
of Shiro authentication, authorization etc and therefore make the required
code from users much less. The Shiro Provider implementation also serves as
a model for those that want to provide another provider and shows the
required adaptor code that needs to be done and how.
Authentication Provider SPI: This is for folks that do not want to use the
Shiro model for whatever reason - and there are plenty depending on what
category of security developer you find yourself in. The standard Servlet
Filter plugin provides the lowest level of integration capabilities and
offers the greatest flexibility. It also requires more work and that is
okay. This is how a Spring oriented contributor could add a Spring Security
provider to Knox.
The implication of this however is that we cannot leak provider specifics
into the overall Knox application by requiring specific implementations of
things like cookies, etc that flow through the entire system and more
importantly need to be understood throughout the system. It is likely fine
to let things flow through that are only understood by the specific
provider components.
We should invest in maturing the Shiro provider to be able to do more and
possible remove the need for other providers in the chain by disabling them
when that provider is sufficient in a given deployment.
That, in a nutshell, is my brain dump on the topic.
On Fri, Sep 20, 2013 at 4: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.
>
