proxy-authentication to SP

[Cantor, Scott]

On 5/7/15, 6:21 AM, "Ulf Seltmann" <seltmann at ub.uni-leipzig.de> wrote:
>
>im not sure if i understand you right, but its certainly because i don't
>know much about oauth2.

Standard OAuth, which is still in scope of OAuth2, is that the target service issues a token to the intermediate service that it itself consumes. There is no middleware involved to broker it and no interop concerns in terms of what the token looks like, it's consumed by its issuer. The issuance process typically involves the client service (foo) redirecting the browser to the target service (bar), which then authenticates the browser (could be SAML SSO, could be anything else) to establish the granting of access by that user to the client service, at which point the token is issued and the browser redirected back to the client service with the token.

That's why it only works one layer deep, the browser is still involved and has to be present at the client service.

OAuth2 adds a more complex refactoring that lets tokens get issued by a third party trusted by the target service, and lots of other complexity that turns it into a poor man's WS-Trust, but that isn't really something you necessarily need in the basic case.

>how would the "foo SP" authenticate a user via OAuth2 to the "bar SP",
>that authenticated to "foo SP" via Shibboleth?

It doesn't, see above.

>Is there some sort of component in a shibboleth-sp that enables it to
>act as a oauth2-client against an oauth2-service or will i just have to
>set up some kind of "trust" setting by myself?

There is no OAuth code of any kind in the SP at present. Adding basic support for issuing and consuming OAuth to protect resources is one of many things that might happen, but that depends on the consortium decisions over the next couple of years. Most people prefer to roll their own scripting code to implement OAuth than rely on middleware written in C++, so there's a basic culture clash in involved, making the audience for such work rather murky. In essence, the thing you're concerned about having to implement yourself is the thing people seem to all want to build themselves. That also limits intrinsically the security of the solution because people don't roll their own "strong security", they just hack in bearer tokens and move on.

-- Scott