On Sun, Mar 7, 2010 at 3:46 AM, Shane Bryzak
<sbryzak@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.
Aaaaah. That paints a much clearer picture.
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.
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 will 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
effort that we otherwise have to put into providing extra security
features in Seam.
Right, that is a good goal.
Hopefully that paints a clearer picture ;)
Much.
-Dan