1. Ad-hoc Lists / Opt-In Problem Definition Access rules for many applications and services cannot be derived from an authoritative source and must therefore be managed in a more ad hoc fashion. This pattern is characterized by the fact that access is manually managed by individuals or self sign-up, not identified registrars. In some cases, authoritative data exists, but is difficult to feed in to the IdM system. In other cases, membership in an access group is entirely left up to individual users or departments to maintain.

2. Ad-hoc Lists / Opt-In Solutions Ad-hoc, static group lists can be used when there is no good way to dynamically manage membership. Managing the group in a central IdM system allows the group membership to be used for multiple provisioning and access management decisions that would otherwise have to be managed in each application. (Similar to white lists.) There may be optional content or services that are offered by the institution that require attributes or group membership in order to participate or not. In addition, there may be information about oneself (person attributes within a directory service) that the user may elect to have public or private. In these cases, it is desired that the users manage and control this access and content, since the items described are optional or user preference.

3. Ad-hoc Lists / Opt-In

5. Examples Project Team At the University of Michigan, access to many systems is dependent upon the successful completion of application-specific training courses or certifications. Course or certification completions are tracked in a variety of isolated side systems that are not easily fed to the IdM system. Static group lists can be created in the IdM system and the individual group membership is either manually managed or periodically synchronized with the appropriate training system according to the requirements of each application. The institution maintains a photo directory as part of the main campus email/phone directory. Some users may wish to not have their photos displayed in the public directory. This is an example of an opt-out service where the individual user is maintaining their own membership in a group. The campus maintains a portal which can generate a variety of content blocks based on role. While some content may be openly available, it is only pushed out to the individual's portal page if the individual chooses to subscribe to it. Again, the individual user is maintaining their own membership in a group in order to subscribe or unsubscribe from this optional content. This is an example of opt-in.

6. Categorization Business Case #4 Wellness Program Participation - A university's HR department offers a health and wellness program for university staff and faculty. The program is entirely voluntary. Participation requires a commitment by the employee to engage in a short online health awareness exercise, in return for which the university offers participants discounts on services at the university health club as well as periodic special offers from area business deemed by the university to be offering wellness-supporting services. A new employee in the physical plant hears about the program during an HR orientation and visits a web site to sign up. Once enrolled in the program, the employee has access to the program's web portal and receives weekly email reminders about training opportunities and special offers. Authority rests with HR department (business role) Grantor and grantee are the same, self-identified but constrained by authoritative source (only staff and faculty) Depending on IAM implementation, could be algorithmic (eg., by eduPersonAffiliation) or more ad hoc (HR provides eligible “staff” and “faculty” lists) Constraint: the grantee must accept terms and conditions of the program before being enrolled.

7. Categorization Academic Case #5 FERPA Information Restricted - Under federal regulations, certain educational records information about students may be categorized as "directory information" and may be disclosed by institutions without prior consent from students. Students reserve the right under FERPA, however, to have disclosure of their directory information blocked upon request. An undergraduate Engineer becomes concerned that a high-school acquaintance may be stalking her, and wishes to have her contact information (name, address, email address, telephone number) blocked from view. The Registrar considers those data elements to be directory information under FERPA, and discloses them by default. The student visits a FERPA portal system and marks those data elements as FERPA protected information in her records. Subsequently, applications that access student educational information and IdM data about students refuse to allow access to the student's contact information except when the requester is identified as having an academic need to see the information. Authority rests with the Registrar (business role) Grantor is self-identified but constrained by authoritative source (only students may exert FERPA rights) Depending on IAM implementation, could be algorithmic (eg., by eduPersonAffiliation) or more ad hoc (Registrar may provide a list of covered students) Constraint: grantees must identify (in some unspecified fashion) an academic need for information