Application |
Purpose (email, science, bug tracking, etc) |
Source |
Language (Perl, C, Java) |
Level of Domestication (see below) : Groups |
Level of Domestication (see below) : Authentication |
Level of Domestication (see below) : Authorization |
Provisioning/ |
Schema Compliance |
Overall certification of Domestication |
Confluence |
Wiki |
Commercial product |
Java |
3, 4 |
2 |
3 |
Possible, not standardized |
None |
Partial |
Grouper |
Group Management |
Apache license; Internet2 |
Java (mostly) |
4 |
3, 1a (UI) |
4 |
web services API; Grouper loader |
SPML2 |
Partial |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
Definition of Application Domestication
The ability to externalize group management, authentication, and/or authorization from within the application, allowing for the use of federated identity by that application.
Note that the targeted audience Application Integrators What does federated groups look like? Would a situation like Confluence that can use LDAP for groups count as level 1 or level 3?
Level of Domestication
Level 5 - planning stages only or not useful = blackbox, internal, not provisionable
Level 4 - purely internal = internal, provisionable
Level 3 - LDAP, not federated
Level 2 - Not standards compliant but offers a local something that could be federated ; community contribution plug-in = external, unsupported
Level 1a - Out of the box works with standard federated technologies, needs simple configuration without writing code = external, supported, federated
Level 1b - external, supported, some additional work needed
App that has hooks built in for SAML (or OpenID, or something like that) is very good, app that has SAML (or something) support built in is good, versus something that as in-house customizable thing that can be used; versus something that only integrates with LDAP (not nec. Useful in a federated environment); versus internal only
Have to write glue code, versus some kind of third-party support, versus vendor support - all means some level of domestication, but imply different amount of work and long-term assurances
What to include - just ones we know about, some "FAQ" type ones, more
This is like calculating LOA. So overall, have a summary level that says, at the end of the day, the app is silver/gold/platinum (tin/pewter/aluminum); model the certification on the InCommon list
Compliance for data interchangeability