HTTP-POST vs. ECP

[Cantor, Scott]

On 7/13/12 5:43 PM, "Jon Carlson" <jon at code42.com> wrote:

>We are in the process of designing SSO plugin support for our enterprise
>backup product.  Shibboleth/SAML will be the first SSO implementation, if
>everything goes as planned.  Thank goodness for OIOSAML.  :-)

I had been unaware that was still being developed, but presumably you
checked. I see Leif weighed in in any case.

>1) My question is, how common is this for desktop and mobile apps?  I'm
>reluctant to build in ECP support if Shibboleth is one of the few SAML
>providers that implements ECP.

I am told that others did, but see no evidence that that's true.
Open-source wise, it's basically non-existent except us, AFAIK.
Corrections welcome.

>2) Do most IdPs out-of-the-box have login web pages that scale well to
>small browser windows?  (think Android, iPhone browsers)  If not, I'm
>assuming that each organization running an IdP can customize this page to
>work in small browser windows.

I don't know what most IdPs do. Shibboleth's is not meant to be used out
of the box without customizing it. Most significant deployments of campus
SSO by now have to have some allowance for mobile browsers. Some have full
mobile support, I'm sure, but probably most just try not to suck too badly.

>3) An ECP question because I think I'm missing something:  The ECP spec
>does not specify how the username and password gets sent to the IdP by
>the client.

Yes, that's for somewhat historical reasons not worth going into here.

>I don't understand that because, using the browser profile,
> an IdP can return whatever form it wants to the browser and the person
>can figure out what goes into the fields presented him.  But a desktop
>app cannot be pre-programmed to stick the username and password into a
>form/message it has no prior knowledge aboutŠ.
> unless it too imbeds a browser for the credential entering.

Yes, actual deployment of ECP requires standardizing that step, and for
conformance purposes it should have been done but wasn't. In practice, you
see basic-auth and client TLS as the main options (and we all laugh at the
client TLS thing, but it's more or less free on the IdP end to support it).

The update to the profile at OASIS will address that more formally, and I
expect SAML 2.1 will include that same updated language. My other work
with ECP is factoring the same assumptions in.

The next IdP release will, I believe, include support for various password
embedding models including basic and WSS Username/Password. But once
you've got HTTP and a fat client, there's no big advantage to doing
anything but basic unless you get more secure and do Kerberos or something.

-- Scott