(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 ;)
On 07/03/10 03:18, Dan Allen wrote:
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?
seam-dev mailing list