As a general comment about role accounts, it is really up to the application in question to support checking user attributes (such as group membership) and authorizing (granting or denying access) based on those attributes. Role accounts often pop up as a work-around when an application doesn’t support group-membership checking.

Ideally, all applications would be configured to authenticate against the Active Directory via its LDAP protocol or the CAS single-sign-on protocol. Once a user’s credentials are verified (authenticated), the user’s groups would be checked against an list of groups allowed to access an application or perform certain actions. Access to the application is then managed by adding or removing users from the group in question. This is how access to private wikis (as well as Drupal pages, Segue sites, many other web applications, file-server shares, etc) are managed.

When choosing and purchasing applications (both vendor-hosted and locally-hosted), support for group-authorizations should be one of the key features required. If this feature isn’t available, then often the only [unfortunate] work-around is to create role-identities with a shared password known by many people. Removal of these role accounts and reconfiguration to use group-based authorization can be done now with any application that supports it. For groups such as student-workers in any particular office, there is no need to wait for the IDM project, these groups can be created in the Active Directory now via Outlook or our web-based group manager.