...
- We need to be able to model a range of different populations. These include museum staff, researchers from other institutions, and public annotators (to track tagging activity). This in turn may place serious demands on the authentication and authorization services, since local institutional Auth/AZ systems may only support employees (e.g., integrated SSO and LDAP systems).
Will we need to have classes of Person that can be associated to different Auth/AZ systems? This kind of puts the AZ cart before the horse (defining some roles in the Person service), but it may be necessary. Or perhaps we will need to have some AZ support for Auth models. We basically need a federated Auth system that can work with unified Person and AZ services.Panel title Resolution [PatrickS]: Authentication, Authorization and Account services are modeled separately. See those services for a discussion of these issues.
- Will we define roles only relative to a Person (Principle), or in some cases relative to an affiliation, so that, e.g., we allow certain permissions to inhere to the curator of another collection? This is not a question about groups and organization, which is separate. It is a question about a logical role association that is defined not relative to a Person but to a position held at an institution (Organization). This may be too complex to bother with, but it would be interesting to know how the functional team feels.
Panel title Resolution [PatrickS]: Authentication, Authorization and Account services are modeled separately. See those services for a discussion of these issues.