OpenSAML user discussion

["Sankaranainar, Naveen" <>]

Yep, my SP configuration got screwed up and after putting the right
timing interval, I am able to federate successfully into google apps.
Thanks for the help!


The contents of this e-mail are intended for the named addressee only. It 
contains information that may be confidential. Unless you are the named 
addressee or an authorized designee, you may not copy or use it, or disclose 
it to anyone else. If you received it in error please notify us immediately 
and then destroy it.

From: Brent Putman 
[mailto:]
Sent: Friday, April 04, 2008 1:24 AM
To: 

Subject: Re: [OpenSAML] RE: Reference Node in Signature Duplicated

Ok.  Just FYI, Will at USC successfully got our Shibboleth 2.0 IdP,
which is build on OpenSAML 2, to work as an IdP for Google apps.  He has
a page here, it's somewhat Shibboleth specific, but there might be some
useful tidbits there.

https://shibboleth.usc.edu/docs/google-apps/

In particular, he indicates that Google wanted a particular NameID
format for the Subject of the Assertion:

urn:oasis:names:tc:SAML:1.1:nameid-format:unspecified

I don't know if that's still current or relevant.  I just mention it b/c
I notice you are instead using the emailAddress format there.   And
also, what you have as a value there doesn't have a domain component
(just "NAVEEN"), which by my read isn't a valid emailAddress value for
that NameID format as per SAML 2 Core, sec 8.3.2.

[** it looks like google is not concerned about the NameID format. If
you look at their static demo it shows emailaddress as the format but
the value is just the user id without domain. So it wasn't an issue. **]

Just some other things I noticed, don't know if any are relevant:

Your AuthnStatement  has an AuthnContextClassRef of:
urn:oasis:names:tc:SAML:2.0:ac:classes:XMLDSig.

Are you really authenticating your users by using XML Signature?  If so,
that's interesting, I've never really seen or heard of anyone doing
that...  I have no idea if Google looks at AuthnContext at all, but I
just noticed it as being perhaps a little unusual.

[** Our application is called TIB (Trusted Identity Broker) and it acts
as a Federation hub
(http://covisint.com/services/idm/tibFeatures.shtml). So in Trusted
Broker model, the federate in users are authenticated into TIB based on
the XML Signature so I thought the auth context
"urn:oasis:names:tc:SAML:2.0:ac:classes:XMLDSig" would be relevant (when
you federate out) until you have second factor of auth after they
federate in from IDP. As you mentioned google is not concerned about
this. I will send you the product link directly, you can check it out.
It uses OpenSAML libraries extensively and also it supports OpenID and
WS-FED. I wrote the WS-FED opensource (openwsfed.com) based on the
OpenSAML libraries and currently working with Chad to integrate with
OpenWS. Hopefully after integration others can use it. **]

For Assertion Conditions you have:
 <saml:Conditions NotBefore="2008-04-02T13:43:53.047Z"
            NotOnOrAfter="2008-04-02T13:43:53.047Z"

The times are the same, so anyone who actually evaluates that is not
going to ever treat the Assertion as valid.

Similarly, your SubjectConfirmationData/@NotOnOrAfter is the same time
as the above Conditions values.  If that was the current time when you
generated, then it's mostly likely going to be invalid when it's being
evaluated by Google's SP (if they evaluate at all...).

Just a few things I noticed.  Google's SP may not care about any of it
though.

--Brent


Sankaranainar, Naveen wrote:
> Brent,
>
> Thanks for the quick response.
>
> Yep, that was the issue. Removed it and now it has only one reference
> but still doesn't work with google. Could be some other issue with
> google.
>
>
>  
>