Right Rights

Access for External Users

Giving external partners access to applications and systems in the cloud works in a similar way to granting access to your own employees. You simply define an appropriate policy that links to people outside your directory. The resources in the package are the same, only the access assignment and reassignment settings that you define in the package are different. When creating packages, you should only add to internal Access packages resources that are accessible only to internal employees.

External partners and suppliers request access the same ways as internal employees, through the My Access portal or from the direct hyperlink to the package. Partners with whom you already successfully collaborate in the cloud can switch to your company in the My Access portal by selecting Switch organizations at top right, where they will find a list of the available access packages. The URL for the package automatically changes the organization, because the tenant (environment) information for the package is embedded in the URL.

If you want new partners to be able to access resources, you typically need to invite users to access your tenant. During the invitation process, AAD creates external identities to maintain references to invited users for auditing, access control, and group memberships. Azure AD automatically creates these accounts when new external partners follow the hyperlink to the package and request access, and you grant access. In this scenario, all new external partners receive a message with a checkbox that must be confirmed to request access.

To create the account in your tenant, the partner must agree to share their name, email address, and partner organization name with your tenant (Figure 3). Although this procedure might sound redundant, it is set up for your privacy. If the request is accepted, the partner can then be found as an external identity in the directory. The permissions from the access package are then assigned with the newly created external identity account.

Figure 3: Access packages are available to external employees, once approved, through AAD B2B collaboration.

Delegating to Departments

ELM in AAD is designed such that the processes of creating and assigning packages and the authorizations lifecycle do not need to be handled by IT. Many of the activities that require approval of access assignments are best handled by the individual departments, because at the end of the day, the staff there are more familiar with the type of resources internal employees require and who needs access to the resources.

Breaking resources down into different packages within a department, such as basic documents, confidential documents, and files containing customer data, is no problem. A Finance catalog defines the different packages as a function of their confidentiality and access requirements; then, you assign policies to the packages and determine dynamically how access and reassignment can occur, strictly on the basis of urgency or confidentiality.

Administrative Authorizations

ELM is also useful for administrative authorizations. You can create your own catalogs with access packages that assign ownership of, rather than membership in, resources such as groups or SharePoint sites.

As an administrator, if you add a SharePoint site or group to a package, you are defining the privileges that members of the resource in question are given. For groups, this can be Member or Owner . For SharePoint, the system also supports ownership for SharePoint sites, to which you can effectively assign administrative authorizations to employees. These authorizations can then also expire automatically after a number of days and need reapproval.