Subject Re: What is a domesticated application?
From Niels van Dijk <niels.vandijk@xxxxxxxxxx>
Date Thu, 17 Jun 2010 22:42:54 +0200

Hi Ingrid, Victoriano,

I would say the amount of domestication required is defined by the demands of the application. We have identified 4 types of applications:

Archetype I (“No identity information needed”)
Archetype I applications have no persistent state, and no need for intra-session up-to-date attributes. For this archetype it is natural to not build up or store any persistent identity information about the user at all. This means that identity information is transferred to this type of application from the IdP at the start of a session (i.e. at sign-in time).
As an example, consider a publisher of scientific texts with contractual agreements with some IdPs (but not all) in a federation for higher education. When users approach the SP they are redirected to their IdP to authenticate. The only attribute of interest is whether the authentication succeeded at an IdP that warrants access to the publisher. There is no need for the SP to remember any identity attributes. The next time a user returns to the SP this process repeats itself and identity information is again transmitted from the relevant IdP.
This is a very 'pure' application archetype. All relevant persistent attributes have been externalised from the SP and reside at the IdP only. No persistent user state needs to be stored at the SP. Many current web-based services in federations are of this simple archetype, essentially using only the authentication features of the federation. This may change as the need of applications for up-to-date attributes changes.

Archetype II (“JIT provisioning is sufficient”)
Archetype II applications do have
persistent user state, but no need for intra-session or extra-session up-to-date attributes. Even though this archetype does store identity attributes at the SP, there is no need to get more frequent updates than the sign-in points in time. An example of an application in this category could be an e-commerce website (say, a web store that sells software products as part of a federation of higher education where students and staff of certain IdPs get discounts). At this SP signed-in users can look at previous transactions or items they have put in their shopping cart during a previous session. Up-to-date attributes for a specific user are only needed when that user signs-in.
There is no need for the SP to handle user data outside of user sessions and there are no interactions between users, whether signed in or not

Archetype III (“Identity information needed during user session”)
Archetype III applications with persistent state, and a need for intra-session up-to-date attributes (for the current user only). This archetype does store persistent identity information of users and needs to make sure, during the user session that some attributes are up-to-date. An example could be a presence or location service, or a blog / forum website which also sends notifications to registered users. Another example of an application in this category could again be an e-commerce web site which sells products for which the user needs to pass some criterion that can only be validated by querying the identity provider in real time (e.g., applications which employ some form of step-up authentication fall in this category).

Archetype IV (“Identity information needed, anytime”)
Archetype IV
applications do have persistent state, and a need for intra- and extra-session up-to-date attributes.
This archetype needs to make sure that attributes are up-to-date independent of user sessions. In some cases up-to-date attributes are needed for processes at the SP
before the user even gets his or her credentials. An example could be a resource planning or workflow system which needs to assign certain tasks to users even if they have not signed in to the system recently (or ever). Another example is an application in which a user can send an email to certain, perhaps dynamically created, groups of users. The application needs to be provisioned with the most recent email addresses of these users, as known only by the IdP.

Currently, most of the SP's we have in our federations are of types I to III. In general using the attributes provided by the IdP will probably be sufficient, although e.g. transporting a large amount of group membership data via SAML may not scale very well.

As may become clear from the above, type IV require the ability to access attributes of either users or groups outside the user sessions. Interestingly, type IV applications are typically very rich in user interaction, and a lot of the 'features' of such an application are strongly dependent on the ability to have access to up to date attribute data outside of user sessions. Next to the examples mentioned, a lot of the collaboration suites like e.g. Sharepoint, Alfresco, Confluence also fall in this category.

For these an out-of-band mechanism seems required to do full domestication, and now we are in trouble :(
Attribute queries could be used, however, these are 'person' centric. This makes it very hard for a SP to get a list of all members of a group. A number of REST or SOAP based quering solutions, like e.g. the Grouper API or the OpenSocial REST API could be used. This works well, but is not standardized, and therefore will have a hard time getting adopted by vendors. SPML is currently the only thing that is both open and industry backed. Yet it is rarely deployed in a federation context (as far as I am aware). This is perhaps because SPML seems mainly desiged to operate in an 'enterprise' environment, where there is only one management domain?

In regard to PIFU is there an API as well as a standard? If so could you point me to the
API definition? My google translate version of did not take me very far :(


On 06/14/2010 09:46 PM, Ingrid Melve wrote:
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?-)