[seam-dev] Project PicketBox v3.0.0.Beta2 is released

[PicketBox JBoss]

I think it makes perfect sense to retain the Seam security API as it is
tried, tested and used.

However, from what I have discussed with Shane, Seam3 internally will try to
use PicketBox for basic security and PicketLink for all the fun SSO/Identity
Management stuff.

Since this is a dev list (and not a user list), I just announced it here.

The goal should be to offload seam developers such as Shane from crazy
security (and its configuration) to focus on what you do best - seam. Seam
Users will probably just look at some annotations to get their stuff
working.

We are only referring to Seam3.

On Sun, Mar 7, 2010 at 2:46 AM, Shane Bryzak <sbryzak at redhat.com> wrote:

>  (Adding Marcel to CC, as he worked on the PicketLink-Seam integration)
>
> Just to clarify a few things with the Seam/PicketLink integration.   The
> core security API in Seam 3 will not be changing drastically, it's a proven
> API and it's what our users are already intimately familiar with.  What we
> *will* be doing is offloading all of the enterprisey-type security features
> such as SSO, SAML, SPNEGO, Kerberos, OpenID integration, etc onto
> PicketLink.  I can't explain 100% how this will be done at this stage
> because I'm just starting to get into the integration work now, however we
> will most likely be providing the following things at the very minimum:
>
> 1) A filter that will propagate any servlet container security context
> (i.e. the logged in user and their roles) to Seam if they are not already
> authenticated (see https://jira.jboss.org/jira/browse/JBSEAM-4559).  This
> feature in itself will take care of a whole heap of the security features
> that I mentioned above, and allow us to remove our own implementation of
> BASIC/DIGEST HTTP authentication (something that would be preferable for us
> not to maintain).
>
> 2) A filter that will propagate Seam's security context to PicketBox.  I've
> written this already (with Anil's help) - what this filter does is allow
> users to use the built-in JEE security annotations, such as @RolesAllowed,
> etc on their beans.
>
> 3) Provide integration with PicketLink IDM via a Seam IdentityStore
> implementation.  This will give our users greater options as to which type
> of security providers they can use for their apps.
>
> This list is just a starting point, and I'm sure as we make some more
> progress we will find more areas where it will be advantageous to have some
> form of tighter integration.  The point of this exercise though is really to
> draw a line between which security features Seam will provide, and which
> features we will delegate to PicketLink.
>
> Our recommendation to users will be to just use the existing Seam Security
> features for their standalone, self-contained apps that require simple
> authentication based on a database or LDAP server.  Once their requirements
> grow beyond this however, our recommendation will be to use
> Seam/PicketLink.  PicketLink will be "the" way to do any
> federated/enterprise identity stuff in Seam.
>
> This will allow us (the Seam team) to curb the amount of development effort
> that we otherwise have to put into providing extra security features in
> Seam.
>
> Hopefully that paints a clearer picture ;)
>
> Shane
>
>
>
>
>
> On 07/03/10 03:18, Dan Allen wrote:
>
> Anil,
>
>  I like the idea that we are separating out the security logic from Seam 3
> so that it can mature and integrate in its own cycles...basically not being
> tied to Seam.
>
>  However, what concerns me is the change in developer experience. Security
> in Seam 2 is so simple to understand. There is barely any configuration, it
> ties in nicely with the managed ORM sessions and it covers role-based,
> rule-based and ACL authorization, plain and simple.
>
>  From looking at the PicketBox wiki pages, I just see a lot of
> configuration that makes my eyes cross. I just don't get what I am looking
> at, really. Either it is going to be more complicated, or you guys just
> don't have a basic example for people to grok. Can you paint a clearer
> picture for us?
>
>  Thanks,
>
>  -Dan
>
> On Fri, Mar 5, 2010 at 12:32 PM, PicketBox JBoss <picketbox at gmail.com>wrote:
>
>> Hi all,
>>    (I created this gmail address for twitter for Project PicketBox. I may
>> as well use it for mailing lists).
>>
>> Shane and I had a couple of days of intense discussion on security at
>> Brisbane last week. Some of those discussions were fed back into the
>> PicketBox project.
>>
>> Read more on Project PicketBox here:
>>
>> http://anil-identity.blogspot.com/2010/03/project-picketbox-security-for-java.html
>>
>> I guess when Seam 3 is released, we are going to offload majority of the
>> security code to PicketBox.
>>
>> I will be loitering around this dev list to basically answer any security
>> related questions.
>>
>> Regards,
>> Anil Saldhana
>>
>> _______________________________________________
>> seam-dev mailing list
>> seam-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/seam-dev
>>
>>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.jboss.org/pipermail/seam-dev/attachments/20100307/faacaf23/attachment.html