Looking for feedback on a first SAML implementation?

You don't need a Subject in the request - looking at the specs, I think it can be this simple.

Up vote 3 down vote favorite 1 share g+ share fb share tw.

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'd be really grateful if some of you would look at my request and response messages and tell me if they make sense for my purpose, if they include anything that doesn't need to be there, and if they are missing anything that does need to be there. Addionally, I'd like to know where in the response I should put additional information about the subject; in particular, the subject's email address. 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 3) User is authenticated/registered by identity provider 4) Identity provider responds to Service provider with authentication success message, PLUS user's email address. Here's what I think the request should be: serviceprovider.com 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 Here's what I think the response should be: 3f7b3dcf-1674-4ecd-92c8-1544f346baf8 urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport So, again, my questions are: 1) Is this a valid SAML interaction? 2) Can either the request or response xml be simplified?

3) Where in the response should I put the subject's email address? I really apprecaite your help. Thanks so much!

-Morgan saml link|improve this question edited Apr 8 '10 at 17:20jsight12.4k44477 asked Dec 21 '08 at 19:37morgancodes4,14032870 59% accept rate.

This belongs on codereview.stackexchange.com – Nix Aug 4 '11 at 12:31.

You don't need a Subject in the request - looking at the specs, I think it can be this simple: Omitting all the optional elements and attributes (Issuer, NameIDPolicy, AssertionConsumerServiceURL etc) means that your identity provider and service provider have agreed these up front, so they don't need to be specified in the AuthnRequest. If you're in control of both ends and you absolutely know that you'll never add another provider to the mix then this is a perfectly legal SAML request. It means "Authenticate the user who presents this via the mechanism we agreed".

Looking at the response, I think this is the minimal case: user@example.com urn:oasis:names:tc:SAML:2.0:ac:classes:PasswordProtectedTransport You can send the user's email address as the NameID, and the AuthnStatement just carries the fact that the identity provider authenticated the user at the given time by the given mechanism. Again, this is stripped to the bone - we omit attributes and elements such as Destination and SubjectConfirmationMethod as they are superfluous to the use case. So, this response says "This is user@example.com; he logged in with a password over a protected transport (SSL/TLS) at 17:13:42 on 11/21/2008".

You should take a look at the SAML 2.0 profiles spec for the exact mechanism for passing these back and forth. The AuthnRequest is usually compressed, encoded and passed as a URL parameter in a GET, while the simplest way to return the Response is via the POST binding - return an HTML page with a form whose target is the service provider, and which is submitted at page load time via some JavaScript.

Most already have libraries to deal with SAML tokens (e.g. Microsoft: WIF). Also, it might be useful to know what kind of service is this: a web app? A web service?

I cant really gove you an answer,but what I can give you is a way to a solution, that is you have to find the anglde that you relate to or peaks your interest. A good paper is one that people get drawn into because it reaches them ln some way.As for me WW11 to me, I think of the holocaust and the effect it had on the survivors, their families and those who stood by and did nothing until it was too late.