Scott,
Thanks so much for the quick and detailed reply. Your suggestion that I use an existing imlimentation has some appeal, however I'd prefer not to have to run an entirely separate webapp just for sso, which seems to be what most existing implimentations are. Ideally, I'd like to use a java library inside our existing app. I thought OpenSAML might fit my needs, but it obviously isn't foolproof enough as it's what I used to generate the flawed SAML I pasted in my original post!
A few more questions for you:
1) Am I right in my assumption that the "existing implimentations" that you refer to will tend to be standalone webapps rather than libraries?
2) Do you know of a java library that will "hold my hand" a bit more than OpenSAML?
Thanks for helping me wrap my head around this stuff! I've looked at dozens of SAML-related web sites and tutorials, poured over the SAML documentation, but am still having a bit of trouble figuring out how this is all supposed to work.
-Morgan
OpenSAML
On Sun, Dec 21, 2008 at 8:09 PM, Scott Cantor <> wrote:
> I've been tasked with designing a very simple SSO (single sign-on)
process.
> My employer has specified that it should be implimented in SAML. I'd like
to
> create messages that are absolutely as simple as possible while confirming
> to the SAML spec.
I have a better suggestion, choose an existing implementation and don't try
and write your own. Anyone else that has to deal with your deployment will
thank you.
> The interaction needs to work as follows:
>
> 1) User requests service from service provider at this point, the service
> provider knows nothing about the user.
> 2) Service provider requests authentication for user from identity
provider
Unless there's only one IdP, you've left out the IdP discovery step.
> Here's what I think the request should be:
You're missing <NameIDPolicy AllowCreate="true"/>, which is almost always
needed because AllowCreate unfortunately defaults to false, creating
implied, largely useless, limitations on what the IdP can do to respond.
Including a Subject is also extremely rare, and including a transient ID in
a request is even rarer, borderline unheard of. Otherwise you're pretty
close.
> Here's what I think the response should be:
Your confirmation Method is incorrect, it should be the bearer method. The
confirmation data also missing NotOnOrAfter, Recipient, and Address XML
attributes, and the assertion is missing an Audience condition. There's also
no signature on the response or the assertion, though perhaps that was left
implied.
All of that speaks to the security of the implementation, so if none of that
was clear to begin with, you're on dangerous ground and may need to go back
and re-read some of this.
> So, again, my questions are:
>
> 1) Is this a valid SAML interaction?
For SSO, no.
> 2) Can either the request or response xml be simplified?
Not really, you're a ways from the minimum.
I'm sure you've read the profile, and I assume core and bindings, but what
you need to do is read the sections of the profile that govern AuthnRequest
and Response usage and you will find the MUST statements covering what you
have to put in them.
> 3) Where in the response should I put the subject's email address?
In a NameID with the emailAddress Format, or in an Attribute.
But I would again urge you to consider choosing an existing solution,
commercial or open source, based on your environment's needs and the scale
of your deployment requirements. Different options will provide different
strengths and weaknesses.
-- Scott
---------------------------------------------------------------------
To unsubscribe, e-mail:
For additional commands, e-mail:
--
+++++++++++++++++++++++++++++++++++++++
morganpackard.com
myspace.com/morganpackard
finediving.org
anticipaterecordings.com
(646) 206-8337
