User Settings in Ad Astra

To access User settings, go to the 'Settings' link in the left navigation panel. You must be an Admin user for your institution to change user settings. 

mceclip0.png

Select Users on the left sidebar or by using the search bar.

mceclip1.png

 

Adding Users

Administrators can add, delete, unlock, and manage permission types for users within User Management.

When adding users, Administrators will need to know the user's First Name, Last Name, and Email Address. Email addresses must be unique for each user.

After adding the user, they will receive a welcome email in their inbox to create a password. They can only create a password through this email unless an administrator unlocks their account. The forgot password link will not work unless the account has been unlocked. If a user does not receive a welcome email, please have them check their junk folder and/or verify the email address “no-reply@verificationemail.com” is not blocked.

 

Unlocking Users

If a user has been added but does not sign in to the application for over 90 days, their account will become locked. Once the user attempts to sign in, they will be alerted of their status. Administrators can unlock users, which will allow the user to reset their own password by clicking the ‘Forgot Password’ link and subsequently sign in to the application.

 

Deleting Users

When a user is deleted, all comments and shared filters are retained and can be viewed by other users.

mceclip2.png

 

SSO Managed Users

Users that are created through SSO are identified by an icon next to the selected role. These users must be managed through the SSO provider.  The ability to delete or unlock these users is not available. 

mceclip0.png

 

User Permissions

There are three options available when updating a user's permission:

  • Admin: have the ability to view the list of users and the ability to update their type
  • Contributor: can create, edit, and delete limited information within the app without having full admin access across all applications. Admins can limit each Contributor’s ability to change information to a set of departments.
    • Clicking "Edit Privileges" in the Actions column will display a pop up to edit which departments the contributor can edit and to toggle on or off publishing privileges
    • Clicking the "Restrict Term Editing..." option will ensure that the user is affected by optional editing restrictions set on the term page.  See Term Settings in Ad Astra

      mceclip0.png

  • User: no access to user Settings or the Pathways app and cannot edit any course or section information, including planned sections or Astra status

    mceclip0.png

Ad Astra consultants and the technical team are listed as "Astra Admin" which can only be edited by Astra Admin.

 

Single Sign-On Configuration

Single sign-on (SSO) allows a user to use one set of login credentials to access multiple applications.  Ad Astra can be configured to use SSO to ease the management of multiple credentials for users.  Admin users have permission to configure single sign-on, select the preferred protocol and configure accordingly. 

When setting up SSO, in some circumstances it can be possible to lock out an SSO managed admin account by mistake. As a precaution, we recommend creating a backup admin account that never logs in through SSO. Use it to fix any SSO configuration issues if necessary.

SAML Configuration

The below information outlines information needed within the application.

  1. Institution Domain
    • This value should be unique to your institution, and as such the suggested format is to use the domain (e.g. uiowa.edu).
    • Characters allowed are alphanumeric, along with - @ = + , .
    Once the Institution Domain is entered, a direct login URL will appear.  This login URL should be distributed to SSO users.
  2. Metadata Document Endpoint URL
    • After configuring your identity provider service with the Entity ID and Destination URL supply the URL for the SAML Metadata Document to finalize the Single Sign-On Configuration.
    • This should be the last field configured - Entity ID, Destination URL and Attribute mappings should precede this field.
  3. Required Attributes
    • Email: This field uniquely identifies users within the Ad Astra system.
      A common value for this field is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/emailaddress
    • Family_name: The users first name.
      A common value for this field is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/surname
    • Given_name: The users last name
      A common value for this field is: http://schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
  4. Optional Attributes
    • Address
    • Middle_name
    • Picture
    • Birthdate
    • Name
    • Preferred_username
    • Gender
    • Nickname
    • Profile
    • Locale
    • Phone Number
    • Updated_at
    • Website
    • Zoneinfo
     
  5. Default Role For New Users
    • This value determines what role users obtain immediately once logging in assuming the user is not an existing user and is not part of a group.
    • The Unassigned Role prohibits the user from getting access to the system until an Admin assigns another role.
  6. Group Mapping
    • Group Attribute Name: This field is a value that corresponds to an attribute provided in the SAML Assertion that denotes the group in which the user belongs in the identity providers system at the institution. If Group Attribute Name is specified you must specify at least one mapping (by using the Add Mapping button)
    • Group Name: This is the specific value that, when matched to the value of the attribute from the SAML assertion will result in the user, within the Astra application, being assigned the value specified in the Role field to the right.
      • Group Name can also be a regular expression for more complex values that may appear for the group attribute.
    When group mapping is configured, only users associated with a group will gain access to the application.  All other users will receive the Default Role For New Users. 

    If group mapping is not configured, a user will be created within the system and the user will receive the Default Role for New Users.
  7. Entity ID
    • This value uniquely identifies Ad Astra as the Service Provider during the authentication flow with your configured identity provider.
    • This value cannot be modified and is supplied to the institution for further configuration with the identity provider service.
  8. Destination URL
    • This URL represents the Single Sign-On (recipient/destination) location to be configured with the identity provider service.
    • This URL appears once Institution Domain, Metadata URL, and required attributes have been configured and the form has been saved.
    • This value cannot be modified.
  9. Save
Users created prior to SSO configuration will be migrated into an SSO user after logging in via SSO.  If group mapping is used, these users will receive the role associated their group. If group mapping is not used, these users will retain their current role.

Here's a diagram that explains what roles users will receive depending on how SSO is configured.

mceclip0.png

Sign-On

Users now have two methods to sign-in to Ad Astra. By email or by institution domain.

Email

In the application, the sign-in screen users are presented with an option to log in by email.

mceclip1.png

Institution Domain

By using the direct URL, users can select 'Sign In with your SSO provider' the user will be redirected to the identity provider to login. If authenticated, the user is sent back to the Ad Astra platform as a valid user.

mceclip0.png

If the user is presented with the incorrect domain, the user can select 'Not from...' to enter a different domain and then sign in through SSO. 

 


Was this article helpful?
2 out of 2 found this helpful

Comments

0 comments

Please sign in to leave a comment.