Refeds


Subject Re: What is a domesticated application?
From Ingrid Melve <ingrid.melve@xxxxxxxxxx>
Date Mon, 14 Jun 2010 21:46:06 +0200

I tried to sum up some of the discussion at
http://identitynetworks.wordpress.com/2010/06/14/domesticating-applications/

Applications should perform well in the environment where they live.
Requests have been made to domesticate applications for higher
education.  Some key elements we ask for in a domesticated application
    * federated login
	(in our case: support SAML2.0 with the SAML2int profile)
    * never touch a password, login is handled in the federation
	(in our case: Feide)
    * consume attributes as defined by eduPerson and additional schemas
	(in our case: norEduPerson, eduOrg and eduOrgUnit)
    * have a reasonable privacy statement, and act accordingly
	(in Europe, se Article 29)
    * if there is need for provisioning, have a well defined		
	provisioning API
	(in our case: PIFU)
    * support virtual organizations and external group management

These requirements are basically the same as you find when people build
their private cloud systems from open hosted applications.

On 01.06.2010 15:45, Victoriano Giralt wrote:
> As one of the "domesticators" maybe my view could be useful.
> 
> As I see, a domesticated application is on that has been adapted to
> federated access management in some way.
> 
> I'd even dare to propose levels of domestication:
> 1) Domestic species. FIAM has been put in by design, with delegation of
> AuthN and AuthR to the federation.

Supports both federated authentication, consumes attributes and may even
be able to talk VO-language.

> 2) Petted species. The application design has allowed to create an
> AuthN(R?) plugin that allows it to smoothly integrate to the federation,
> maybe with a minimal local user provisioning.

Federated authentication, consumes attributes (possibly combined with
back-channel provisioning using standard API).

> 3) Tamed applications. They have been made to play in the federated
> environment by way of provisioning local users on the fly with kind some
> kludge, but AuthN/AuthR happens mostly at application level but with
> information carried over from the federation, but do not ask for
> username and password.

This category I do not understand. Could you give an example?  I would
have thought that Tamed applications were using LDAP access to the same
source as the IdP in federations, but that may be half-wild apps?-)


Ingrid