delegation questions

[Cantor, Scott]

On 5/11/12 8:35 AM, "Age Jan Kuperus" <AgeJan.Kuperus at wur.nl> wrote:
>
>Now we have a new situation, in which one of these applications will also
>act as a backend for several other applications. We think delegation is
>the most appropriate way to handle this. We tried to partly implement the
>ECP profile, so far without success: after disabling some backend SP
>checks we managed to get a valid SAML token for the backend, but the
>final redirect went to the application's base url instead of the
>requested url.

There's nothing you should need to disable, and unless you corrupt the
RelayState handling, it will end up  at the right URL. You have to
*enable* delegation itself in the SP security policy to start with, but
other than that it works more or less automatically on the backend. The
work is all with the IdP and the client library.

>Question 1: do we need extra configuration in the backend beyond what is
>documented in 
>https://spaces.internet2.edu/display/ShibuPortal/Configuring%20Shibboleth%
>20Delegation%20for%20a%20Portal
>?

Nothing I'm aware of, apart from some bugs involving ECP that we've found
and fixed, but those are SP bugs that would prevent the ECP challenge in
the first step.

>The general idea here is that there must be a simpler, pure REST-based
>way to handle it.

If you want to use OAuth, use it, but I recommend that you throw most of
the SAML out in the process. Mixing them is mostly going to waste your
time.

The lack of a sound framework for authentication in HTTP remains a
dealbreaker for me in pursuing a "REST" model. The client/IdP step needs
to be flexible enough to accommodate a lot of authentication models, and
HTTP is not. I don't care that much about the rest of the flows, but ECP
was the most convenient mechanism because it was already defined and
implemented.

If you're having problems implementing it, I can understand quite easily
that the IdP half would trip you up, but the SP half is trivial XML
manipulation.

> Given four parties: the user, the IdP, the main application (protected
>by SP1) and the backend application (protected by SP2), the first three
>parties can use the browser profile but SP2 can only respond to SP1. As
>SP1 knows that SP2 might need authorization, it should be able to ask the
>IdP for a delegated SAML assertion and pass that in a HTTP header.

SAML assertions don't fit in HTTP headers, and even if they did, you would
want to exchange them for a cookie-like thing to streamline follow-up
requests, so I don't see the size issue as relevant, or worthy of
inventing a whole new framework to fix. Artifacts do fit, but there's no
point in reinventing OAuth to accommodate them, just use it instead.

>Question 2: Is there, or are there plans, for something like that?

No.

>Question 3: Would it be difficult to implement, or are there serious
>disadvantages?

Implemented properly, it's fine, but our goal was to build delegation with
SAML, not to mix in a new framework. I don't consider the alternatives
simple to implement unless you throw out most of the security and take a
lot of shortcuts. Once you add that back in, you end up back where you
started.

-- Scott