Thanks a lot Scott. I understand it is not a good approach to follow now. I need to think about something else.<br><br>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.<br>
<br>There are some ways that I can think of to archive it:<br>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.<br>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?<br>
3) I was think to have Server acting as SP, but it seems not realistic.<br>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.<br>
<br><br>Best,<br clear="all">Yaowen<br>
<br><br><div class="gmail_quote">On Mon, Jul 16, 2012 at 2:21 PM, Cantor, Scott <span dir="ltr"><<a href="mailto:cantor.2@osu.edu" target="_blank">cantor.2@osu.edu</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">On 7/16/12 3:11 PM, "Yaowen Tu" <<a href="mailto:yaowen.tu@gmail.com">yaowen.tu@gmail.com</a>> wrote:<br>
><br>
>4) We still want server to do the real authentication. Basically, we want<br>
>to integrate the SP into server instead of the web app. Is it possible to<br>
>archive that?<br>
<br>
</div>Yes, by adding a second SSO protocol into the picture and linking your web<br>
app and your "server" using that second protocol. The SAML part ends at<br>
the server, and the rest is your business to implement.<br>
<div class="im"><br>
> For example, an use case would be(not sure if it is realistic): user<br>
>send a SOAP message that contains username and password, then server talk<br>
>to IdP and finish the authentication. In this case, there is no browser<br>
>needed.<br>
<br>
</div>No. You do not get the password, period.<br>
<div class="im"><br>
>5) I just came across SAML Enhanced Client or Proxy, which seems to be<br>
>helpful to my case. Also it seems Shib SP and IdP support ECP. Can you<br>
>tell me what is that used for? A real example would be great to help me<br>
>to understand better.<br>
<br>
</div>It's not relevant to your situation. You do not have a non-browser client.<br>
Your clients are still browsers.<br>
<br>
You're trying to create a scenario where you still get the password<br>
because that gives you a lot of flexibility. Yes, it is true that if you<br>
did, your server would not be a browser and if you wanted to "scrape" IdPs<br>
in an attempt to get by one, you could use ECP in some sense. But you<br>
shouldn't, and that design is the opposite of federation. You might as<br>
well drop that part and just tell your customers they have to let you talk<br>
to their LDAP or Kerberos back-end. Some of them will let you, and some<br>
will tell you to forget it. But the reasoning will be because you're<br>
insisting on getting the password.<br>
<br>
If you want to handle customers that refuse to let you see their<br>
passwords, then if you don't want to do SAML on your application server,<br>
then you're going to have to do something else instead to bridge to<br>
whatever you do for federated SSO.<br>
<div class="HOEnZb"><div class="h5"><br>
-- Scott<br>
<br>
--<br>
To unsubscribe from this list send an email to <a href="mailto:users-unsubscribe@shibboleth.net">users-unsubscribe@shibboleth.net</a><br>
</div></div></blockquote></div><br>