COmanage Developers List

[Niels van Dijk <>]

Hi Tom,

On 04/13/2010 04:01 PM, Tom Barton wrote:
> Niels van Dijk wrote:
>> Next up the generic webproxy for authenticating and provisioning
>> (remote) apps.
>> It is often a lot of work to domesticate an application by actually
>> changing it, and sometimes even impossible, as in our test case (Adobe
>> Connect), when it is a closed source app, or the app lives 'in the
>> cloud'. However, a number of apps do have APIs for authentication and/or
>> provisioning.
>> The basis idea was therefor to have a standardized, configurable
>> domestication 'device', in our case an Apache reverse proxy in front of
>> the (remote) application. 
> 
> Use of reverse proxy for authenticating in some circumstances is clear.
> And you know I like the JIT provisioning approach. I wonder if there may
> also be other approaches, and if you guys discussed any others. For
> example, if a user is first "invited" to the collab platform, any user
> account provisioning might be triggered in that workflow. And when
> someone puts the user into a collab group or removes them from it, that
> event might trigger a corresponding provisioning action.
> 

In broader sense, we investigated generic usecases and solutions for
provisioning in identity federations last year. see:
<http://www.surfnet.nl/Documents/indi-2009-07-019%20(Provisioning%20and%20deprovisioning%20in%20an_identity%20federation_final-1.2).pdf>
(sorry for the horrible URLs)

The above concludes that a 'centralized' component for provisioning and
deprovisioning is a usefull asset for any kind of federation model.
Also it seems that if you have a set of 'related' services a centralized
platfom is conveniant. It might be said that a VO platfom +  SP's is
such a set of 'related' services where the VO could provide some service
for (de)provisioning the apps, and the same would go for a set of campus
services.

In regard to other appoaches: One JIT flow we have currently adapted for
one of our services is doing authentication via SAML, provide a eppn as
part of the attributes, and then provision all stuff via a REST API.
(currently Grouper's API) based on queries using the eppn. This works
very well. Only problem is that groupers API is not an open standard.
That's why I got interested in the OpenSocial Rest API, as it does the
same thing, but this time based on a standard.

There is a new report on the way, where we have looked more specifically
in scenario's for deprovisioning. As soon as it is past the draft stage
I'll be happy to point you to it.

regards,
Niels


-- 
Niels van Dijk
Advanced Services

T: +31 302 305 337 / M: +31 651 347 657
SURFnet - PO Box 19035 - NL-3501 DA Utrecht - The Netherlands -

http://www.surfnet.nl
SURFnet - We make innovation work