Portal-style ECP and the Social2SAML problem
Keith Hazelton
happen. E.g. a backend service is called from the "portal" and our
preferred mechanism for that is good old SAML ECP.
Now what if we want browser users to be able to authenticate to the
portal via either SAML IdPs or selected Social IdPs?
If we're talking Social2SAML gateway solutions that gets confusing to
me.
How does it look if we consider the "native support in the Shib SP"
approach to support for other AuthN protocols
--Keith
--
To unsubscribe from this list send an email to dev-uns...@shibboleth.net
Cantor, Scott
> happen. E.g. a backend service is called from the "portal" and our
> preferred mechanism for that is good old SAML ECP.
There have been, AFAIK, no serious use cases presented for *federated* n-tier delegation, and the lack of support for that capability makes that pretty unlikely at scale unless there are serious incentives at play.
But another way of saying it is that you have to map out all the players and who and what they want to trust to control things, and then map that to the actors you need to have in a transaction.
> Now what if we want browser users to be able to authenticate to the
> portal via either SAML IdPs or selected Social IdPs?
Obviously those IdPs will never support SAML or any delegation model based on it. If you have a gateway involved, and if the back end services equally trust that gateway as an IdP, then of course the gateway can broker delegation too.
The use of OAuth to do authentication itelf is very limited, that's why OpenID Connect has to profile it. Adding delegation to that means adding to it. I don't know if that work is done, planned, partially proposed, or ignored.
OAuth as a delegation facility is focused on one tier in, and having the portal send the client to the service you want access to to authorize the token to access it. So that's an option, and of course is the one the typical developer today will think is the right one. In that standard OAuth mode, the service itself acts as the authority and issues the permission token to the portal after authenticating the user (with SAML, or anything else).
> If we're talking Social2SAML gateway solutions that gets confusing to
> me.
That's less confusing if you want to broker it all with the gateway. But trying to do both OAuth and SAML is definitely a mess.
> How does it look if we consider the "native support in the Shib SP"
> approach to support for other AuthN protocols
The delegation profiles we defined for SAML assume that you have a SAML assertion as a SSO token and an STS/IdP that will exchange it for a new one hop by hop. If there's no SAML assertion, you have to have a different solution.
The SP itself really knows nothing about any of this. The only pieces it includes right now related to delegation are:
a) support to block or limit delegation *to* itself
b) some hacks to help application code get what it needs to do the delegation work
If I eventually add code to do more things on behalf of the application, that's all it is, just code to offload a particular way of doing things to the SP on behalf of the app. It's still the application doing "something", because that's what the use case is. The application *is* the client. The SP where the application lives is really just there to secure the app and help it do things it might want to do.
If you mean the SP that's in front of the back-end app being delegated to, then the answer is, other profiles involving SAML or something not SAML could be defined that are means of authentication to that SP and it would support them, or not, as usual.
For example, if somebody wanted to have an app that was behind a SAML SP, but also accepted OAuth authorization to a REST API, one could imagine building that into the SP, or using the idea I suggested for third party authn code integration. Do the OAuth work in your scripts, funge a SAML assertion representing the security context of the caller, feed that into the SP and get the cookie back and have the caller use that to make calls through the standard SP layer.
I doubt most people would see that as too useful, vs just putting the REST API on its own terms and doing OAuth, but it could be done.
Basically, if you take delegation and *add* more protocols for authentication, don't be shocked that you get a giant ball of "what a mess". When you take a hard problem and then add "and screw your standard, wah wah, we're doing something else" and have a mix of incomplete, immature approaches that don't even claim to solve your problem, you will have a hard time solving the problem cleanly. You're very far into "invent a lot of security orchestration" territory.
-- Scott