On Sun, Mar 7, 2010 at 3:46 AM, Shane Bryzak <sbryzak(a)redhat.com> wrote:
(Adding Marcel to CC, as he worked on the PicketLink-Seam
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
Aaaaah. That paints a much clearer picture.
Our recommendation to users will be to just use the existing Seam
features for their standalone, self-contained apps that require simple
authentication based on a database or LDAP server.
It's also important that we get something out there for early adopters of
Java EE 6 to use...because people are getting restless having figured out
that a decent security solution is still missing from the platform. We want
them to latch onto Seam rather than inventing their own solution (that we
then have to complete with or convert them from).
So let's just keep in mind that we need that standalone solution out there
before too much time passes by.
Once their requirements grow beyond this however, our recommendation
be to use Seam/PicketLink. PicketLink will be "the" way to do any
federated/enterprise identity stuff in Seam.
It's good that we are thinking broader because this is exactly where we fell
short in Seam. The Seam 2 security is very easy to pick up and start using,
but when apps require a centralized security model, Seam scrabbled a bit to
make that happen--and in many cases just couldn't.
This will allow us (the Seam team) to curb the amount of development
that we otherwise have to put into providing extra security features in
Right, that is a good goal.
Hopefully that paints a clearer picture ;)
Senior Software Engineer, Red Hat | Author of Seam in Action
Registered Linux User #231597