A mail distribution list (mail DL for short) is a list of identities to which an e-mail message can be sent, such that every member of the list will get a copy of the message. Mail DLs can be represented in most directories, such as LDAP servers or Active Directory.
On some directory systems, a mail DL can include both user objects and SMTP e-mail addresses. Lotus Notes is an example of a system that supports mail DLs with these two types of entries. On other directory systems, mail DLs can only contain a list of objects -- either user objects or contact objects (i.e., objects that contain contact information for a person, such as the person's SMTP address, but which cannot be used as login accounts). Active Directory is an example of this.
IAM systems can be used to manage the membership in mail DLs, just as they can be used to manage membership in security groups. In technical terms, mail DLs are almost indistinguishable from security groups, except that they cannot be used to grant security rights to their member users.
Hitachi ID Identity Manager can manage membership in existing groups and automatically detects new groups, which can subsequently be enabled (manually or automatically) for Hitachi ID Identity Manager management.
Group membership management can be driven by multiple processes, including:
- Calculated membership (typically based on identity attributes);
- Self-service and delegated requests, with or without approval;
- Access certification (event-triggered and scheduled);
- Role based assignment (assign roles, automatically assign/revoke groups in those roles);
- Segregation of duties policy (between groups, roles, accounts);
- Out-of-band change detection (followed by alert or undo);
- Reporting (ad-hoc and scheduled).
- A correct model of group hierarchy -- child groups nested into parent groups.
Requests for group membership are often difficult for users to articulate. Users want to access a "thing" -- a share, folder, application or screen and may not understand that this access right is linked to a group, or what group is needed.
There are several approaches to helping requesters formulate suitable access requests:
- Automation: to the extent possible, automatically assign
access rights to users based on available identity attributes
and a role model, eliminating the need to submit or approve
- Search: help requesters find suitable
entitlements by searching on name, description or other metadata.
- Filter: limit available entitlements to only those that
make sense for a given requester and recipient. Search is easier
to use if the set of possible options is as small as possible.
- Intercept: wait for users to attempt access (which they
are not yet entitled to). Intercept "access denied" error messages
and help the user navigate directly from the initial error dialog
to an appropriate access request page.
- Selective copy: show requesters the differences between
an existing user (who has a desired entitlement) and another user
(who does not have it yet, but needs it). This is a variant of
search where the requester knows who can do something and will be
able to select the appropriate entitlement from the short list of
differences between a reference user and a recipient.
- Recommend: users have peer groups -- i.e., other users who perform similar functions. The Identity and access management (IAM) system can show a requester entitlements that are popular among the peer group of a given user, but that the user in question does not (yet) have. The desired entitlement is very likely in this list.
Group membership changes can also be formulated from the perspective of either users or groups. i.e., "add these users to this group" or "add these groups to this user."