...
| Criteria | Without eduTEAMS | With eduTEAMS |
|---|---|---|
| Effort for Deployment | Little effort if Initially, little deployment effort is needed for an application that already contains an own user management and access control mechanisms. In the long term, if multiple applications are used by a research community, deployment efforts are still slightly smaller than with eduTEAMS but identity management becomes a much greater scalibility bottleneck as is written below. | Moderate for the first time because an OAuth implementation or a SAML Service Provider has to be deployed (and potential code to access group information via VOOT). |
| Identity Management | Either done by the research community as a whole (see above) or has to be all done by service operator in case the application's own user management is used. In the later case, this can be quite some effort to do properly for more than a hand full of users. | Not needed, done by the user's home organisation (i.e. university, research institute). |
| Data Quality | Degrading quickly after user account was provisioned by research community | Personal user attributes are released by user's home organisation (e.g. university) that has a good interest to keep data up-to-date |
| Access ConrolControl | Unless a shared user directory is used, access control rules have to be defined per service per user, which is quite some effort and needs frequent adaptations | Easy to define access control/authorization rules based on group membership data |
| Security | User has to authenticate at each service with his credentials. The more services are used, the higher the risk that one of the services is compromised and thus the user credentials are compromised | Service never gets users credentials. Even if service is compromised, the user credentials are not affected by this, only the user's data on this service. |
...