<div class="gmail_quote">On Sun, Mar 7, 2010 at 3:46 AM, Shane Bryzak <span dir="ltr"><<a href="mailto:sbryzak@redhat.com">sbryzak@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff">
(Adding Marcel to CC, as he worked on the PicketLink-Seam integration)<br>
<br>
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.</div></blockquote><div><br></div><div>Aaaaah. That paints a much clearer picture.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff">
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. </div></blockquote><div><br></div><div>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).</div>
<div><br></div><div>So let's just keep in mind that we need that standalone solution out there before too much time passes by.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div text="#000000" bgcolor="#ffffff"> 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. <br></div></blockquote><div><br></div><div>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. </div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div text="#000000" bgcolor="#ffffff">
<br>
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.<br></div></blockquote><div><br></div><div>Right, that is a good goal.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div text="#000000" bgcolor="#ffffff">
<br>
Hopefully that paints a clearer picture ;)<br></div></blockquote><div><br></div><div>Much.</div><div><br></div><div>-Dan</div><div><br></div></div>-- <br>Dan Allen<br>Senior Software Engineer, Red Hat | Author of Seam in Action<br>
Registered Linux User #231597<br><br><a href="http://mojavelinux.com">http://mojavelinux.com</a><br><a href="http://mojavelinux.com/seaminaction">http://mojavelinux.com/seaminaction</a><br><a href="http://www.google.com/profiles/dan.j.allen">http://www.google.com/profiles/dan.j.allen</a><br>