why is SAML based on browser

[Cantor, Scott]

On 7/16/12 3:11 PM, "Yaowen Tu" <yaowen.tu at gmail.com> wrote:
>
>4) We still want server to do the real authentication. Basically, we want
>to integrate the SP into server instead of the web app. Is it possible to
>archive that?

Yes, by adding a second SSO protocol into the picture and linking your web
app and your "server" using that second protocol. The SAML part ends at
the server, and the rest is your business to implement.

> For example, an use case would be(not sure if it is realistic): user
>send a SOAP message that contains username and password, then server talk
>to IdP and finish the authentication. In this case, there is no browser
>needed.

No. You do not get the password, period.

>5) I just came across SAML Enhanced Client or Proxy, which seems to be
>helpful to my case. Also it seems Shib SP and IdP support ECP. Can you
>tell me what is that used for? A real example would be great to help me
>to understand better.

It's not relevant to your situation. You do not have a non-browser client.
Your clients are still browsers.

You're trying to create a scenario where you still get the password
because that gives you a lot of flexibility. Yes, it is true that if you
did, your server would not be a browser and if you wanted to "scrape" IdPs
in an attempt to get by one, you could use ECP in some sense. But you
shouldn't, and that design is the opposite of federation. You might as
well drop that part and just tell your customers they have to let you talk
to their LDAP or Kerberos back-end. Some of them will let you, and some
will tell you to forget it. But the reasoning will be because you're
insisting on getting the password.

If you want to handle customers that refuse to let you see their
passwords, then if you don't want to do SAML on your application server,
then you're going to have to do something else instead to bridge to
whatever you do for federated SSO.

-- Scott