Re: [saml-dev] Any 3 leg profile?

[Will Hartung <willh@mirthcorp.com>]

On Wed, Feb 27, 2013 at 9:04 AM, Cantor, Scott <cantor.2@osu.edu> wrote:
> On 2/27/13 12:00 PM, "Will Hartung" <willh@mirthcorp.com> wrote:
>
>>By 3 leg I mean client authenticates with IdP, gets Token, client then
>>makes request to SP with Token, that the SP verifies/accepts Token and
>>delivers the service.
>>
>>Is there another term of art for this?
>
> Hmm, that sounds like basic SSO to me. SAML has always had that.

Actually I guess I misspoke.

It's sort of like ECP, but not sure if it's the same thing.

We're talking about a web client here.

Browser -> AppA, AppA identifies with IdP on behalf of client, and
passes back credential to the client. Client then takes the credential
to connect with AppB.

The issue is that the Browser (initially) never gets to talk to the
IdP, so the IdP can not start a session up with the Browser. The AppA
will redirect the Browser to AppB, along with a token in the URL, and
AppB takes the token, bounces the browser off of the IdP to establish
the session, and then were in normal SSO mode with the token acting as
the credential (rather than prompting for a username/password).

> I think you probably want to look at ECP then, if the problem is that the
> client's not a browser. In its pure form, it still relies on a server
> challenge to get the flow going, but there are ways to supplement that,
> and frankly, it's not clear a challenge from the server isn't a good model
> anyway, since it allows for RP influence over token characteristics.

"RP"?


> By three-legged, I assumed you meant client talking to server talking to
> back-end service on behalf of client, i.e. delegation. Which I have also
> used ECP to model, but it's a more complex scenario with more
> supplementary specs.

Yea, looking at ECP, as presented looks much like the web profile with
the client acting as the auto-submit form does in the Web Profile. I
don't think that's quite our use case here.

The Application (AppA in this case) could do that. act as an ECP, but
it can't pass a session to the browser once it's done.

AppA has the credential information to authenticate the client, in
this case AppA is not part of the normal SSO environment, but
ancillary to it.

Dunno if any of that helps.

Thanks again, Scott.

Regards,

Will Hartung
(willh@mirthcorp.com)

-- 
CONFIDENTIALITY NOTICE: The information contained in this electronic 
transmission may be confidential. If you are not an intended recipient, be 
aware that any disclosure, copying, distribution or use of the information 
contained in this transmission is prohibited and may be unlawful. If you 
have received this transmission in error, please notify us by email reply 
and then erase it from your computer system.