supporting IdP-initiated SSO only

[Peter Williams]

Not particularly hypothetical, in my experience (of a few hundred SAML2 or variant deployments, now, over 5+ years).

 I'd say 80% of all saml2p-ish websso in US realty is idp-initiated. The only deployments where it's sp-initated always (almost) is when interworking with a commercialized Shib install. I'd say 99% of the transactions are idp-initiated.

I've found 3 drivers for sp-initiated (which we support, BECAUSE of the wonderful architectural benefits that come with it, whether the flow is then used or NOT).

1) security doctrine on how ideal security systems (set by committees) OUGHT to be. Typically, there is a huge  
gulf between the class of folks on committees and related folks who deploy according to best practice. The gulf is similar to those who design tax codes those who fill out the forms; or those who sell mortage backed options in wall street and the $10 an hour immigrant from central America with a 7th grade education, who is set on buying a mortgage.

2) political entities like incommon, that have a particular management model for interworking and cooperation. Such may rely upon the enforcement properties of the security doctrine.

3) a vendor wants to strip value from the SP, placing it the hands of the IDP. The vendor often argues that  companies SP's cannot be trusted in a public policy sense (where  some other largely identical company now running the IDP role server can...).

I've found that almost none of the 3 drivers resonate in the commodity marketplace. They may resonate in academic and research networks, however. The reason for the non-resonance is that the motives  interfere with local economics and politics - which may . In some economic areas, you may then be affecting the livelihoods of a half million (typically older) people (who typically resist change, till an OVERWHELMING and entirely OBVIOUS benefit emerges).

I've found that there is (in US realty) no equivalent of incommon. It costs very real cash money to run, and no one will pay in mainstreet business models funded by folks earning perhaps $30k a year (while operating in the US economy, with its horrendous operating costs). Where  one get can government funds to fund a research network, obviously life is different.


-----Original Message-----
From: dev-bounces at shibboleth.net [mailto:dev-bounces at shibboleth.net] On Behalf Of Ian Young
Sent: Saturday, March 16, 2013 11:00 AM
To: Shib Dev
Subject: Re: supporting IdP-initiated SSO only


On 16 Mar 2013, at 16:57, Tom Scavo <trscavo at gmail.com> wrote:

> I thought I knew the answer to this question but now I'm not so sure...
> 
> Suppose a Shib IdP supports SAML2 IdP-initiated SSO only. What does 
> its metadata look like?

Kind of an interesting hypothetical.  Can you explain why a Shib IdP would choose to only support IdP-initiated SAML 2.0 SSO?  That would mean it didn't support the SAML 2.0 Web Browser SSO Profile.  Unsolicited responses are only an optional part of that profile.

> Since an IDPSSODescriptor MUST include at least one 
> SingleSignOnService endpoint,

This is related to the fact that the Web Browser SSO Profile in the SAML 2.0 specification involves the SP sending a request to the IdP.

> I'm not sure how to answer that
> question. Seems the only option is to define a custom RoleDescriptor.

If you define a custom RoleDescriptor, no SP will understand it.

	-- Ian