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.

Top

Application information

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

• If your website/application is already registered, you may select it from the Application name drop-down box. 
• If your website/application is not already registered, check the Register a new application check-box, and your website/application will be registered as part of this request. 

Registering a new application:

• Under the Application Instances builder, add a record for all environments that are part of your application. 
• There are also options for Mobile, Desktop and Other Applications.
• Mobile/Desktop/Other application types should be given a name.
• Web Site application types should be given an Environment type (Prod/QA/Dev) and a URL.
• One Hosting Portal record will be created for each application type/environment.
• Hosting Portal records will be grouped by the New Application Name field above the Application Instances builder.

Updating an existing application:

• During an update, the service type requested will apply to all environments displayed. 
• If this is not the desired outcome, make a note in the non-technical explanation section and have a conversation with your technical representative about which environments the update should apply to. 

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. 

Top

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:

• UMD
• UMCES
• USMO
• UMES

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

UMD sub-categories:

• UMD - Current Students
• UMD - Affiliates
• UMD - Employees
• UMD - Associate Accounts (uncommon)
• UMD - Former Students (uncommon)

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

Top

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:

• Normal Attribute Group.
• Critical Attribute Groups .
  
  • UID Attribute Group.
  • Campus Contact Attribute Group.
  • Personal Contact Attribute Group.
  • Email Attribute Group.
  • Employment Attribute Group.
  • Affiliate Attribute Group.
  • Courses Attribute Group.
  • Student Attribute Group.
  • Service Attribute Group.
• Other Critical  Attributes. 

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).

Top