why is SAML based on browser

[Yaowen Tu]

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.

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.
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?
3) I was think to have Server acting as SP, but it seems not realistic.
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.


Best,
Yaowen


On Mon, Jul 16, 2012 at 2:21 PM, Cantor, Scott <cantor.2 at osu.edu> wrote:

> 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
>
> --
> To unsubscribe from this list send an email to
> users-unsubscribe at shibboleth.net
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://shibboleth.net/pipermail/users/attachments/20120716/d9ab753c/attachment.html