why is SAML based on browser

[Paul Hethmon]

I'll just reiterate some of Scott's points. It really seems that you have
a hammer and every problem is a nail. SAML is designed to solve a common
use case. I believe you either use it or use something else.

Typically what happens when the "application" loses the authentication
process, is that it simply does everything else but that. The act of
consuming and validating the SAML assertion is the authentication step.

You mentioned needing the user's password (which you should never get or
see). I would ask why? If you trust the assertion, what value does the
password add? Obviously you can get at the necessary data without it. If
your application has established the trust, why do you need to do it a
second time?

Paul



From:  Yaowen Tu <yaowen.tu at gmail.com>
Reply-To:  Shibboleth Users <users at shibboleth.net>
Date:  Monday, July 16, 2012 5:09 PM
To:  Shibboleth Users <users at shibboleth.net>
Subject:  Re: why is SAML based on browser


Paul,

Thanks for your quick response. Maybe I didn't describe my case clearly.
There are some limitations that make me want to use server instead of our
web app to act as SP:

1) Our server and web app are two separate applications. They are usually
deployed on different machines. If the web app act as SP, then web app
could trust the authentication, but we still need to build some mechanism
for server to trust this as well.

2) In real production deployment, our web app and server may even sit in
different layer, it is also possible that web app will not be allowed to
connect to customer's LDAP or IdP servers.

3) In our current architecture, our web app is not responsible for any
authentication. Everything is done in server.

Based on the above three limitations, I am exploring some possibilities to
integrate SP into server. That is why I am asking the questions. Maybe
SAML is not designed for my such case. I am just trying to see if there
are any options that I am not aware of
 can archive my goal, for example ECP?


Best,
Yaowen


On Mon, Jul 16, 2012 at 12:41 PM, Paul Hethmon
<paul.hethmon at clareitysecurity.com> wrote:

>From:  Yaowen Tu <yaowen.tu at gmail.com>
>Reply-To:  Shibboleth Users <users at shibboleth.net>
>Date:  Monday, July 16, 2012 3:11 PM
>To:  Shibboleth Users <users at shibboleth.net>
>Subject:  Re: why is SAML based on browser

I think you are missing the point of SAML SSO. SAML is meant to hand off
the authentication step to a third party. Why even support SSO?



>2) They now talk to each other using SOAP message, so currently web app
>will send a SOAP message to server to do login, and server will do >the
>real authentication


And SAML removes the need for that. Instead your SOAP message might just
obtain any user information without validating credentials.

>3) Now I want to integrate SSO into our product. If I install the Shib
>SP, essentially it is the web application(including SP and our own >web
>app) that does the authentication, not the server any more.


Correct.

>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? 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.


Why? You don't gain anything. Either the SAML assertion validates or it
doesn't. If it does, then you trust it. Moving the validation of the
assertion to another server doesn't make that anymore secure or better. It
only complicates your life.

If the end user is in a browser interfacing with your web app, then the
web app is the relying party.

Paul


--
To unsubscribe from this list send an email to
users-unsubscribe at shibboleth.net <mailto:users-unsubscribe at shibboleth.net>