Portal, API (Web Service Provider) and sessions

[Cantor, Scott]

On 5/17/12 9:38 AM, "Matteo Bertazzo" <m.bertazzo at cineca.it> wrote:

>we're wondering what the best way to manage the following scenario.

I would avoid words like best. There is no consensus on most things, so
asking what's best depends on who answers.

>We're using shibboleth in order to authenticate users to a web Portal.
>The user activity on the portal generates a series of REST calls from the
>Portal Application (ie PHP HTTP client) to a remote REST API (Web Service
>Provider).

Well, our implemented (but essentially prototype) model for that is what
you found. I addressed the questions raised about doing it "simpler" in a
message last week or so.

>When a Portal's call arrives the Web Service Provider application has to
>retrieve the identity of the user "generating" the call.

Yes. Our approach to that is that we want the protection on the back end
to be the same as what's on the portal (the SP), and I think web services
ought to be relying on the web server for security the same as web apps
should be.

>In other words, the API can't rely on a username specified by the Portal,
>it must use a "token" (toward the IDP?) to determine which logged user
>should be associated with a particular action.

That's what delegation is, yes. I don't know what you mean by "toward the
IdP" exactly.

>Given that:
>- The application that implements the Web Service Provider could become a
>SP
>- We can use ECP compliant SPs
>- We can change the Portal side in order to support an identified
>solution, i.e. based on tokens
>
>we're wondering if we have to "explore" the "ECP and delegation" side
>(maybe a subset 
>ofhttps://spaces.internet2.edu/display/ShibuPortal/Solution+Proposal, the
>third profile)
>or if a quick-and-dirty approach is doable (just verify a token?).

Your use case is identical to the one in that proposal/prototype.
Literally identical, it was the exact scenario that led to the work done.

-- Scott