Shibboleth Developers

[Peter Williams <>]

Ok. I want to review (like an anal-mode security evaluator must, from first 
principles and text) the notion for third party initiated one more time 
(since we are going to deploy it in the core platform this afternoon). Note I 
said notion - vs compliance to some draft OASIS  document. It's support for 
the management principle that I'm after, at this point.

(a) SAML2 requires use of the AuthnRequest protocol
(b) a signed request can be received from third party by first-party IDP, on 
a standard endpoint
(c) IDP can return an unsolicited response to a second-party SP

(d) the logic used by IDP to require signatures on requests and then connect 
(b) to (c) is 100% an operational policy matter.
(e) the audience condition of the response is at the discretion of the IDP, 
tho MUST include the second party and MAY include the third party.

(f) Formally, the IDP is entirely entitled to play the role of the third 
party.

-----Original Message-----
From: 

 
[mailto:]
Sent: Tuesday, October 07, 2008 9:44 AM
To: 

Subject: RE: [Shib-Dev] idp-initiated SSO


I didn't consider the failure a bug when I noticed it would not interoperate. 
 I generally considered the 3rd party initiated SSO to be a hacked solution, 
so I did not expect it to consistently work.  The third party request profile 
looks interesting, and I can see some value in it.  Although I think Peter 
Williams is correct in that there is a subtle difference in whether it's 
truly 3rd party initiated when it is the IDP (perhaps not the software, but 
the entity/system) trying to initiate the Unsolicited SSO.


-----Original Message-----
From: Scott Cantor 
[mailto:]
Sent: Tuesday, October 07, 2008 12:31 PM
To: 

Subject: RE: [Shib-Dev] idp-initiated SSO

> This technique works fine Shibboleth to Shibboleth, but in my
> interoperability testing with some commercial products, it is inconsistent
> as to whether it works.  The IDP populates the InResponseTo attribute, and
> according to the SAML standards it "MUST NOT contain an InResponseTo" for
> Unsolicited Responses.  I know that when I did some testing with CA
> Siteminder, it failed with an error about unrecognized Response ID.
>
> Is there a way in the spoofing to tell the IDP to leave out that
attribute?

That's what the extension Nate mentioned was for (among other reasons). If
you follow the spec, both the IdP and the CA SP are doing the right thing,
so they're not buggy.

If you wanted basic support for the third party request profile, maybe just
with unsigned requests to solve this basic problem, you could file that in
jira.

-- Scott