UMD Enterprise Directory: Requesting SSO & Integration Services

In this article 

About the form

The SSO and Enterprise Directory Integration Request form allows you to request Single Sign-On (SSO authentication) and information retrieval integration services for your application from the Enterprise Directory (LDAP). CAS and SAML are the primary protocols that are supported. Non-SSO authentication options are also available for special cases. 

After your request is submitted, it will be reviewed by the Enterprise Directory administration staff, your Unit Head, campus Data Stewards, and IT Security/Compliance teams, as necessary, for approvals of the specific user populations and data attributes for your application.


Application information

All applications receiving SSO/Authentication services must be registered via the DIT Hosting Portal (either in advance, or via this request process).

Registering a new application:

Updating an existing application:

Service type requested

The form can be used to request single sign-on authentication, attribute retrieval, or both. For each service (authentication and/or attribute retrieval), you must choose a protocol.  You do not have to use the same protocol for authentication that you use for attribute retrieval, though it may be convenient to do so.  The supported protocols are CAS, SAML, and LDAP.  If you select LDAP (i.e. AuthDN) for authentication, additional security reviews are required that may delay the processing of your request.  These additional security reviews do not apply to information retrieval via LDAP/AuthDN. 

For all requests, you will need to identify which populations you want authentication and/or attribute retrieval for. Populations are covered in the following section. 

For attribute retrieval requests only, you will need to specify which data types (i.e. attributes) you are requesting. Attribute groups are covered below. 


User populations requested

The form presents a decision-tree, starting with the four institutions that have information in the Enterprise Directory. As a result of your selection, you will be given access to one or more access groups defined in the Access Model article. 

The four institutions are:

Several sub-categories are available for UMD persons.  The Enterprise Directory only contains employee information for the other three institutions. 

UMD sub-categories:

Additional sub-categories are available for the "UMD - Employees" option. 


Data types requested

For the populations that you have access to, you may also request attributes to be returned for those users. These attributes are managed in groupings. The fields included in each group are defined in the Access Model article. (For additional details about Enterprise Directory attributes, including basic logic for how they are populated, see the Enterprise Directory Schema article).

Note: Although approval is granted for groups of attributes, if you select attribute retrieval via the CAS or SAML protocols, only the specific attributes you describe in the free-text field will be configured for access by your application at the time of initial implementation. Additional approved attributes can be configured for access by your application without submitting another request. Approval for additional attribute groups would require a new request in order to route the new approvals. 

Available Groupings:

Attribute privacy flags also apply to certain attributes. 

The Normal Attribute Group contains attributes that are defined as public access and every authorized application automatically has access to them.  

Attributes that are not Normal Attributes are considered to be Critical Attributes and applications must request access to them. Most of these attribute have been collected into to sub-groups for purposes of managing access. 

Other Critical Attributes are not part of any group and must be requested on an attribute-by-attribute basis. These attributes are not maintained as part of a group because either they are application specific, and/or they are especially sensitive with respect to identity theft. 

Certain attributes are modified by various true/false privacy flags. For example, attributes from the address, phone and email groups may already be granted depending on who is making the request (e.g. telephoneNumber is treated as a public attribute for employees).