why is SAML based on browser

[Cantor, Scott]

On 7/16/12 5:49 PM, "Yaowen Tu" <yaowen.tu at gmail.com> wrote:

>Thanks a lot Scott. I understand it is not a good approach to follow now.
>I need to think about something else.
>
>My ultimate goal is: Web app can trust the user passed over from SP, but
>I need to build some mechanism for server to trust this user as well.
>There are some limitations that I have described in my previous response
>to Paul.

I didn't see any reason why the "server" matters at all, other than as
some existing authentication mechanism that should be irrelevant here. The
usual answer is that your existing mechanisms should be abstracted behind
an IdP that you operate to handle non-federated authentication. The usual
response to this from vendors is "no", but that doesn't change the fact
that the alternatives are worse for the user interface and in terms of
integration work.

>There are some ways that I can think of to archive it:
>1) Build our own mechanism between our web app and our server. That is
>doable but requires a lot of work and not a favorable solution.

It's the only one you have if that server is in any way involved.

>2) web app still act as SP, then web app capture the whole Assertion, and
>forward it to our server. Server verify this Assertion. Is that a good
>approach?

No, not really. It means implementing your own SAML stack from scratch.

>4) Can you think of any other better solutions? I have very limited
>knowledge, so I need experts like you to give me some advises on how to
>archive this goal.

See above. Take all your existing mechanisms for authentication and put
them behind an IdP. The web application relies on one protocol, SAML or
otherwise, to handle all authentication.

This applies regardless of whether you're doing SAML, OpenID, or CAS. The
point is, limit the application integration to one mechanism and bury the
rest behind that abstraction.

-- Scott