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

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?-)