deltaspike-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Lincoln Baxter, III" <>
Subject Re: [DISCUSS] Security and IDM for DeltaSpike
Date Wed, 15 Feb 2012 17:29:06 GMT
I think there are a few key things to keep in mind for our security

   1. Accurate, intuitive documentation with a clear path to get started.
   2. Technically correct implementation that allows for things like custom
   password encryption strategies.
   3. Consistent API/SPI package naming

What was done in Seam Security is very good, but the extension points were
all over the place. It was unclear when to use PicketLink APIs and when to
use Seam Security APIs. The process of specifying identity management
implementations was a bit strange. You had to set the authentication
strategy you want to use into a bean manually before attempting that form
of authentication.

I think it would be nice to specify many types of authentication strategies
which would determine which type of authentication is being invoked (chain
of responsibility) and handle that automatically. Of course there should
also be a programmatic API to control this explicitly, but it should not be
required up front.


On Mon, Feb 13, 2012 at 2:56 AM, Boleslaw Dawidowicz <> wrote:

> Hi,
> As this is my first post on this list I will introduce myself shortly. At
> the moment I'm a project leader of GateIn Portal (JSR 168/286
> implementation). Like Shane mentioned I implemented PicketLink IDM
> component which is mostly an API/SPI for Identity Management -
> users/groups/roles related operations, LDAP and RDBMS storage support and
> etc. This project is currently used by portal as it's core component and
> was partly reused by Shane in Seam Security. Recently we were brainstorming
> about new iteration around IDM and Seam Security and he proposed to bring
> this discussion here.
> On my side here is recent attempt to shape minimal API/SPI having
> simplicity in mind:
> Obviously I hope to get involved in DeltaSpike beyond scope of identity
> topic only :)
> Bolek
> On Feb 10, 2012, at 3:04 AM, Shane Bryzak wrote:
> > Hi guys,
> >
> > I'd like to kick off a discussion around the security features for
> DeltaSpike.  Originally we had planned to migrate Seam Security [1] to the
> PicketLink project [2], and combine it with an updated version of
> PicketLink IDM [3] to create an all-round CDI-based application security
> solution for Java EE6.  After a number of internal discussions, we decided
> that this effort would serve the developer community much better if it were
> carried out under the DeltaSpike umbrella.
> >
> > With that in mind, I'd like to introduce Bolek Dawidowicz (who has
> already joined the DeltaSpike dev mailing list) who is the original author
> of PicketLink IDM (for anyone that's confused about what IDM is, it stands
> for IDentity Management and simply means the management of users, roles,
> groups etc within an application via a well defined API).  Bolek has
> already done some initial design work on the API for PicketLink IDM 2.0
> [4], which we are hoping to leverage for DeltaSpike.
> >
> > I'd also like to kickstart a discussion on the more general security
> features of DeltaSpike.  We've already discussed @Secured and
> @SecurityBindingType, however have not touched on any of the other
> authentication and authorization APIs.  My proposal is to largely base the
> design on Seam Security (code at [5]), which is already mature and proven,
> and provides a robust, extensible API for users to plug in their own
> authentication and authorization logic, and also integrates very easily
> with federated identity services such as OpenID, oAuth and SAML.
> >
> > At this stage we can keep the discussion on general terms, however I'm
> happy to delve in deeper to any of the security APIs if anyone is
> interested in a more technical discussion.
> >
> > Thanks,
> > Shane
> >
> >
> > [1]
> > [2]
> > [3]
> > [4]
> > [5]

Lincoln Baxter, III
"Keep it Simple"

  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message