protecting web services w/ shib

[Cantor, Scott]

On 4/23/13 4:15 PM, "Liam Hoekenga" <liamr at umich.edu> wrote:

>We could also use something already generated by the IdP as the access
>token (the session token?), but it would need to be something that WSO2
>could validate independently.  I'm not sure that WSO2 could do anything
>useful with session token, or if we could some how forward on the SAML
>assertion that the IdP provided to the SP during authentication.

You're free to code up anything you like obviously, and the IdP and SP can
communicate just about anything in an attribute, but there's no guarantee
that existing plugins on either end are sufficient to accomplish something
like that without adding code. They may be. I added various attribute
decoding plugins that can do some more advanced things.

I don't know what session token you're talking about above, but it is very
doubtful it has any relevance here.

SAML assertions for browser SSO are not forwardable by default and do not
act as delegation credentials.

ECP, in a couple of different forms, is the only other SAML-issuing
profile in the Shibboleth software besides the browser use case. ECP is
designed for any flow in which there's a standard SP component on the
server side and something that's not a browser on the client side. Web
services is an example of that use case, except that web service code you
would find in any given toolkit will never understand ECP. It's custom
work.

There aren't any endpoints in the IdP that just magically return a SAML
assertion with custom content, and there aren't any standards that would
guide us to know what to implement for something like you're describing.

>I've done a few searches in the mailing list archive and saw the
>suggestion that shib was never intended to protect web APIs.

Well, there are no widely accepted standards for protecting web APIs.
(Hand waving with the word OAuth in it doesn't count as a standard, at
least for me.) If something emerges that is a real standard that suggests
some kind of role for a Shibboleth product, then it's certainly a
candidate for implementation. Many probably think that¹s OAuth. Maybe
someday.

My experience over the decade and more I've worked on the project is that
people, when faced with the work involved in protecting such APIs, end up
punting to simpler point to point security in most cases, and that has led
us to avoid much investment in the problem.

To date, the support we provided for APIs is based on ECP. It is designed
much like everything else is, with the goal of pushing all of the server
side controls into the SP software, and NOT allowing the web service to do
anything related to identity. The SP pushes in the headers like in other
cases.

The SP and IdP support this out of the box. But as I said, no clients do.
There are ECP implementations around, some of which are linked in the wiki.

True delegation by user to service client is an additional layer of
complexity to the problem and requires additional pieces. We have some
extensions to the IdP that support this and are still debating whether to
roll that work into 3.0, mostly depending on time to do it.

-- Scott