1:55 p.m.
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(a)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(a)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-...
>
> 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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/seam-dev
>
>