Manage Users and Authentication

Users are defined within MetaKarta in order to:

Identify authorship of objects and originator of an action
Define session counts for licensing or usage of the product
Assign various global roles directly or through group assignment.

Please refer to the responsibilities and capabilities assignment model for an explanation of how users relate to role assignment.

Any of the external SSO (LADP, QAuth, etc.) will create users in the system as side effect of a successful login of a new user.

In addition, there are a few ways that multiple users can be created in the same minute.

• Import users from an external file on the Manage → Users page.

• Restore

• Calling the REST API POST /admin/users via a program.

In those cases, the new users are created by the user who performs the Import users operation, restore operation or the REST API user.

Listing All Users

The list of users present in the Manage Users page is paginated for larger lists. You may locate a user in the pages of the list by way of the Search text field in the upper left of the Manage Users page.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Enter the text to search for in the Search Text box to quickly find one or more users with matching textual information.
Page through the list of users, specify a given page and control page size.
Add and/or Delete users in the list.

Multi-selection is allow in the user list with Shift-click and Ctrl-click.

Specify user Authentication settings.
For native users, specify the MAX FAILED LOGINS allowed.
For all users, specify the TIMEOUT before automatically ending an authentication session due to a lack of activity.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the top banner.

Information provided about users in the list not in the object page:

Locked --
Active Sessions -- Number of sessions that user is consuming (concurrent users).
Last Login -- Last time the user initiated an authenticated session.

Enter "bob" in the box.

Now, enter "stu" in the box and right-click Stu and you have context menu options:

These are all covered in the sections below.

Edit User Account Details

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Select the user from the list.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the top banner.

Click on the user to edit, Stu.

Click on the Properties tab.

Here you may edit:

USER NAME and CHANGE PASSWORD. If the user is a native user then these fields may be edited.

If the user is managed outside of MetaKarta (e.g., LDAP, OAuth or SAML) then the USER NAME will not be editable and CHANGE PASSWORD will not be displayed)

DEFINITION. Information about the user.
FULL NAME. Full name of the user.
EMAIL. Email address of the user.

The DEFINITION, FULL NAME and EMAIL of the user may be already be populated at login if the user is managed outside of MetaKarta (e.g., LDAP, OAuth or SAML). You may update this information manually here.

GROUPS. Pick list of groups which a user may be assigned to.

The group assignments you make here to the user will be replaced at login if the user is managed outside of MetaKarta (e.g., LDAP, OAuth or SAML) and you are using automatic group assignment.

GLOBAL ROLES. Pick list of global roles which a user may be assigned to.

Click the "x" next to an assigned global role name to remove the assignment.

NOTIFICATION FREQUENCY to set how often you are notified of changes, which can be either:
Never
Daily
Near Real Time
Weekly (Day of week)

With Daily notification, there is a scheduled job named Send scheduled notifications and the time of day when the notification occurs may be set there.

With Near Real Time notification, the frequency is based upon the specified by the administrators.

Review User Statistics

Detailed user session statistics may be downloaded.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Select the user from the list.
Click the Period Statistics tab and specify any PERIOD to report statistics for that user.
Click the Activity Statistics tab to see statistics on the activities of this user (e.g., Certified Objects, etc.).,

Example

Sign in as an Administrator and go to MANAGE > Users in the top banner.

Click on the Administrator user and click the Period Statistics tab.

Period: Specify the period of time over which the statistics will be presented.

PERIOD SESSION COUNT: Number of logged in sessions for that user during that period.
PERIOD SESSION TIME: Total time of logged in sessions for that user during that period.
PERIOD OPERATION COUNT: Total number of operations executed by that user during that period.
PERIOD OPERATION TIME: Total time of operations executed by that user during that period.

Click the Activity Statistics tab.

Edit User Preferences

One may clear user preference settings (impacting the UI) using the Preference tab when managing a user. You may wish to clear these out when encountering UI issues.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Click a user.
Go to the Preferences tab.
Use Delete to clear one of the preferences.
Use Remove all at the top of the list to delete all the current preferences.

Edit User Custom Attributes

You may define and associate values for custom attributes on users. The process is identical to assigning custom attributes on any other object in the repository.

One may clear user preference settings (impacting the UI) using the Preference tab when managing a user. You may wish to clear these out when encountering UI issues.

Steps

If not already defined, create a new custom attribute on the User class type.
Sign in as a user with at least the Metadata Editing capability object role assignment.
Go to the object page for the data element.
Go to the Overview tab.
Click on the More actions icon next to Attributes and select Add custom attribute(s).
Select the custom attribute(s) to include.
Edit their values in place.

Unlike labels and comments, custom attributes may only be assigned or edited with the proper permissions on the model that contains the object.

You may also edit custom attributes using the context menu when you see an element in a list or do so in bulk.

Example

Create the User Address custom attribute as in the example in add a new custom attribute.

Select User as the Scope

Create the new User Address attribute type.

Assign it to the User Object.

Go to MANAGE > Users, refresh the browser and select the user named Bob. Enter a new USER ADDRESS. Click SAVE.

You may also edit this information in the user profile page for that user.

Delete a User

You may delete any username from MetaKarta. However, externally authenticated users will be recreated if that user signs in and is again properly authenticated.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Click a user.
Click the Delete icon.
Click YES to confirm.

Open User Profile

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Right-click on a user from the list and select Open User Profile.
From here you may:
Click the link to the right of any entry in STATISTICS and you will have a worksheet with that query in the current configuration.
Click EVENT TYPES or pick a DATE range to choose which events are shown in the ACTIVITY STREAM.

Click the Email address to send email to that user.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the top banner.

Right-click on the Administrator user and select Open User Profile. Go to the History tab.

Click EVENT TYPES and choose only New.

Return to the Overview tab. Click on the link (5 in configuration) to the right of Certified Objects in STATISTICS and you will have a worksheet with that query in the current configuration.

Show Customizations

You may see the customizations a user owns including collections, worksheets, dashboards, default worksheets and presentations and change the owner of those customizations.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Right-click on a user from the list and select Open Customizations.
From here you may:
Go to the type of customization you want to see:
Collections list
Worksheets list
Dashboards list
Change owner.

Example

Sign in as Administrator.

Go to MANAGE > Users in the top banner.

Right-click on the Administrator user and select Show Customizations.

Here you may set the maximum number of sequential invalid login attempts that may be made against any native user.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Specify the maximum number of sequential invalid login attempts that may be made against any native user in the MAX FAILED LOGINS pulldown.

Exceeding the number specified of invalid login attempts locks that user. In order to login again, the user account must be unlocked via MANAGE > Users.

Example

Sign in as Administrator.

Go to MANAGE > Users in the top banner.

Specify the "3" as the maximum number of sequential invalid login attempts that may be made against any native user in the MAX FAILED LOGINS pulldown.

Log in as the user Bob but with an invalid password. Now, do so again:

On the second attempt and failure to login, you see User account will be locked on the next failure.

Log in one last time as Bob with an invalid password.

On the third failed attempt the user account is locked. You see User is locked.

Now, log back in at Administrator or any user with the Security Administrator capability global role assignment, and go to MANAGE > Users.

The user account Bob is locked.

Unlock the account by selecting the account and clicking Unlock.

You may lock any account at any time as long as you have the Security Administrator capability global role assignment.

The Administrator user account cannot be locked out.

Once a user account is locked it must be Unlocked. Simply disabling the MAX FAILED LOGINS does not unlock those user accounts.

Set the Session Timeout

Here you may set the inactivity time limit that triggers the automatic end of a login session

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Select the amount of time to maintain a session with inactivity in the TIMEOUT pulldown.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the top banner.

Select the amount of time to maintain a session with inactivity in the TIMEOUT pulldown.

Import Users

This feature allows the administrator to update the users or create new users from the conf/UserDirectory.csv. A template file is located in the $MM_HOME/conf/Templates directory in the installation.

Upon external authentication (LDAP, OAuth and SAML2), a valid user is created in the system (if not already there) based upon those credentials from the external authentication authority and will then be in MANAGE > Users. Thus, there is no need to import users in these external authentication scenarios.

You may create the required CSV file from that template.

This process is not simply a merge. It attempts to completely modify the existing set of users, and:

Merges with existing users
Creates new users
It DOES NOT delete existing users which are not in the CSV file.

There is no UNDO for this action.

Steps

Copy the file UserDirectory.csv from $MM_HOME/conf/Template to $MM_HOME/conf.
Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Click the Import users from an external file icon.
Click RUN OPERATION.

You may also schedule it as a scheduled operation.

Example

Copy the file UserDirectory.csv from $MM_HOME/conf/Template to $MM_HOME/conf and make the necessary changes, including new users and changes to existing users.

Mapping between the columns of UserDirectory.csv and the user properties in MANAGE > Users.

UserDirectory.csv column	UserDirectory.csv column	UserDirectory.csv column
User property	User property	User property
Definition	Definition	Definition
User Login Id	User Login Id	User Login Id
User Name	User Name	User Name
Must be specified	Must be specified	Must be specified
User Full Name	User Full Name	User Full Name
Full Name	Full Name	Full Name

The entries in this file can be used to import both native users and external (LDAP, OAuth and SAML) users. The product checks if the user already exists by matching the User Login Id with the user names in the system.

If there exists a user in the system whose name matches the User Login Id, that user will be updated using the values specified in the file. Only the user properties that have a non-empty value in the file will be updated.
If the User Group Name is specified, the user will be removed from the existing group assignment(s) and added to the new group(s). Any invalid group name specified in the User Group Name column will cause an error to be logged in the operation log. If the user is the Administrator the group property will not be updated.
If the existing user is an external user and a non-empty User Password is specified in the file, the password will be ignored, and a warning will be logged in the operation log.
If there is no user in the system whose name matches the User Login Id a new user will be created using the values specified in the file.
If the User Password is specified, the user will be created as a native user; otherwise the user will be created as an external user.
For LDAP users the User Distinguished Name is mandatory. It corresponds to the the distinguished name (DN) of the user in the LDAP directory, e.g. "CN=John Doe,CN=Users,DC=miti,DC=local".

No users in the system will be deleted even if they are not in the file.

Please refer to the automatic group assignment rules for external users at the user login time. If an external user belongs to an external group and there is a group mapping/assignment between the external group and a local group, the user will be automatically assigned to the local group, despite what was in the UserDirectory.csv.

Download Users and Statistics

A complete report of users may be downloaded.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Click the Download icon.

Example

Sign in as Administrator and go to MANAGE > Users in the banner.

Click the Download icon.

You may download either CSV files or XLSX files. The XLSX file have special handling which safeguards against CSV Injection, also known as Formula Injection, which is a security vulnerability that occurs when untrusted input is included in a CSV file.

Special Users

The Administrator user has all privileges, is not a member of any group and cannot be deleted. It is the only user defined when the product is first installed.

Manage Authentication

Upon external authentication (LDAP, OAuth and SAML2), a valid user is created in the system (if not already there) based upon those credentials from the external authentication authority and will then be in MANAGE > Users. Thus, there is no need to import users in these external authentication scenarios.

Manage Native Authentication

In this mode, users may be defined as a user defined locally within MetaKarta. All create, edit, group assignments and deletion actions on that user may only be made within MetaKarta.

When logging in using native authentication mode, if the user name is associated with a native user the system will authenticate that user with native authentication (based on the local password).

Set Native Authentication

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Select Native from the Authentication pull-down.

Example

Sign in as Administrator.

Go to Tools > Administration > Users.

Select Native from the Authentication pull-down.

Create a New Native User

Native users are manually created/updated by the Administrator. A Native user is required to have a password defined at the creation time. Native Users can coexist with LDAP users, which may be useful in creating temporarily logins for administrators, support, consultants, etc.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Click the icon.
At the bottom of the screen, in the Properties tab, provide a Username, Password, and other identifying information.
Check the Named License checkbox if you want to designate this user as a named user for licensing purposes.

Only available if named user licenses are enabled.

Assign a group to the user.
Assign global roles to the user.

Example

Sign in as Administrator.

Go to MANAGE > Users in the top banner.

Click Add. At the bottom of the screen, in the Properties tab, provide a Username, Password, and other identifying information.

See more details about editing a user account.

Click CREATE.

Manage LDAP Authentication

In order to leverage existing LDAP users and ensure that they may use their existing authentication when accessing this product, there is an LDAP authentication mode in MetaKarta. In general, the process is:

Set LDAP authentication mode.
Configure the connection to your LDAP environment.
Optionally configure automated group assignment based upon LDAP attributes.

Once the above is completed, existing LDAP users may simply sign in with their LDAP credentials and they will be identified users in MetaKarta.

Upon external authentication (LDAP), a valid user is created in the system (if not already there) based upon those credentials from the external authentication authority and will then be in MANAGE > Users. Thus, there is no need to import users in these external authentication scenarios.

Set LDAP Authentication

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Select LDAP from the Authentication pull-down.

Example

Sign in as Administrator.

Go to MANAGE > Users.

Select LDAP from the Authentication pull-down.

As you are altering the methods of authentication which are in effect, you will receive a confirmation dialog.

Click YES.

Configure LDAP Authentication

Once you have enabled LDAP authentication, configuration is based upon defining the proper connection to the LDAP server.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Be sure LDAP Authentication is enabled.
Click the Configure Authentication icon.
Specify the Type of LDAP to be used, which are a set of pre-defined attribute mappings. These include:
Microsoft Active Directory
Open LDAP
IBM Tivoli
Novell EDirectory
Sun System Directory
Custom.

If you select Custom, you may specify further in the Attribute Mappings tab.

With Windows Active Directory, it is generally best to use to the UPN (User Principal Name) format (e.g., USER@FQDN) instead of the Windows domain style (DOMAIN\USERNAME) format (e.g., corp\mc25438. In fact, the Active Directory is configured as a forest, it is mandatory to use the UPN and switch from the default port to the global catalog port as well.

Enter the connection parameters available in the Connection tab.
Enter the mapping information for LDAP attributes in the Attribute Mappings tab.
Use the Test button to validate the settings.
Go to the Group Assignment tab to auto-assign groups based upon the LDAP security model.

Example

Sign in as Administrator.

Go to Tools > Administration > Users.

Select LDAP from the Authentication pull-down.

Specify Microsoft Active Directory as the Type of LDAP to be used.

Enter the connection parameters for the LDAP server.

The URL is generally in the format:

ldap://<server name or IP address>:<port>

The User and Password are just for testing and configuration purposes.
Set TIMEOUT (SECONDS)

If you are seeing slow performance when authenticating LDAP users, oftentimes what is taking the vast majority of the time is retrieving the data from the LDAP server. This may often be the case when you are using Microsoft Active Directory on the default port 389. It is recommended to switch to the global catalog on port 3268 (generally the same URL but with the different port).

Click the TEST button to validate the settings.

Go to the Attribute Mappings tab to define user attribute mappings.

Go to the Group Assignment tab to auto-assign groups based upon the LDAP security model.

If you do not click the TEST button, a test connection will be attempted anyway on clicking OK and it must pass successfully before the dialog closes. You may always click CANCEL to cancel the change.

Create a New LDAP User

There is no need to create an LDAP user manually. Instead, an LDAP user is automatically created/updated as a result of a successful LDAP authentication login. Thus, all that is required is that the user/password combination is valid for the LDAP authentication connection definitions and query rules.

The LDAP user attributes (login, full name, e-mail, description, etc.) are automatically mapped to selected LDAP attributes (e.g. sAMAccountName is used by default for login on Microsoft Active Directory). In addition, one may change this mapping using the Advanced LDAP connection button.

Manage OAuth Authentication

Configuration of MetaKarta to support an external SSO environment requires working with your System Administrator. In this mode, the system default login page is disabled and not presented. It must be replaced by an external authentication login system.

Administrators can always login even in External Authentication Mode using the dedicated administrator rescue login URL: http://localhost:/MM/Auth?nativeLogin, where is the http port that MetaKarta responds to.

The OAuth specification defines a delegation protocol that is useful for conveying authorization decisions across a network of web-enabled applications and APIs. OAuth is used in a wide variety of applications, including providing mechanisms for user authentication.

MetaKarta supports the OAuth 2.0 protocol for external authentication.

Upon external authentication (OAuth), a valid user is created in the system (if not already there) based upon those credentials from the external authentication authority and will then be in MANAGE > Users. Thus, there is no need to import users in these external authentication scenarios.

Set OAuth Authentication

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Select OAuth from the Authentication pull-down.

Example

Sign in as Administrator.

Go to Tools > Administration > Users.

Select OAuth from the Authentication pull-down.

Configure OAuth Authentication

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Select OAuth from the Authentication pull-down.
Click Configure Authentication.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the banner.

Select OAuth from the Authentication pull-down.

Click Configure Authentication.

# Configure the OAuth Server

In order to enable an external authentication server using the OAuth 2.0 protocol, the Administrator needs to configure the OAUTH server. The following example shows the Configure OAUTH Server editor parameters using the Google server.

Steps

Sign in as a user with at least the Application Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Click Configure Authentication.
Go to the Connection tab.

Example

The user needs to obtain OAuth 2.0 client credentials, such as Client Id, Client Secret from the external authentication server, such as Google and Facebook.

Besides the Client Id and Client Secret, the OAUTH Server configuration also requires the external authentication server Authentication URI, token URI and a few other parameters:

Authentication URI: a URI on the external authentication server that handles the user authentication. The result is an authorization code, which the application can exchange for an access token and a refresh token.
Token URI: a URI on the external authentication server that exchanges the authentication code for an access token.
Validation URI: a URI on the external authentication server that validates the access token and provides access to the user's account
Scope: One or more scope values indicating which parts of the user's account an access token permits.

Go to the Attribute Mappings tab to define user attribute mappings.

Go to the Group Assignment tab to auto-assign groups based upon the OAuth security model.

# Add an External Authentication User

External authentication users are automatically created/updated by successful external authentication login. They are assigned groups according to the rules provided by the authentication system, or the guest group by default.

One may specify additional group assignments manually (see Assign a group to a user).

Request Headers

The Request Headers tab specifies extra parameters to be added in the HTTP requests to the external authentication server by MetaKarta.

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Click Configure Authentication.
Go to the Request Headers tab.
Click the Add action icon.

OAuth authentication workflow

A Client submits an authentication request via the User Interface of a Resource Server
The Resource Server presents the Client with an Authorization Grant, and redirects the Client to the Authorization Server
The Client requests an Access Token from the Authorization Server using the Authorization Grant Code
The Client logs in to the Authorization Server, and if the code is valid, the Client gets an Access Token that can be used to request a protected resource from the Resource Server
After receiving a request for a protected resource with an accompanying Access Token, the Resource Server verifies the validity of the token directly with the Authorization Server
If the token was valid, the Authorization Server sends information about the Client to the Resource Server

Signing in with Google

In this case the MetaKarta application server is the Resource Server, the Google Authorization Server is the Authorization Server, and the end user is the Client. The OAuth server configuration parameters should look like those in the screenshots in the Configure the OAuth Server section.

Once you have specified OAuth External Authentication Mode

MetaKarta presents the end user with an Authorization Grant, and redirects the end user to the Google Authorization Server's Authentication URI https://accounts.google.com/o/oauth2/auth. The scope values "email profile" indicates that we are not requesting access to the user's Google data, just wanting to know the user's email address and basic profile information.
The end user requests an Access Token from the Google Authorization Server's Token URI https://accounts.google.com/o/oauth2/token, using the Authorization Grant Code.
The end user logs in to the Google Authorization Server, and if the code is valid, the end user gets an Access Token that can be used to request a protected resource from MetaKarta.
After receiving a request for a protected resource with an accompanying Access Token, MetaKarta verifies the validity of the token and gets the user's name and other profile info directly with the Google Authorization Server by sending a validation request to the Google Authorization Server's Validation/User Info URI https://www.googleapis.com/oauth2/v3/userinfo using the Access token.
If the access token is valid, the Google Authorization Server sends information about the end user based on the scope values to MetaKarta. Below is an example of the data in JSON.

{ "sub": "110248495921238986420",

"name": "Aaron Parecki",

"given_name": "Aaron",

"family_name": "Parecki",

"picture": "https://lh4.googleusercontent.com/-kw-iMgD_j34/AAAAAAAAAAI/AAAAAAAAAAc/P1YY91tzesU/photo.jpg",

"email": "aaron.parecki@okta.com",

"email_verified": true,

"locale": "en",

"hd": "okta.com"

}

Using the given User Attribute Mapping, Google's name attribute is mapped to this products login and full name attributes, Google's sub attribute is mapped to distinguished name attribute in MetaKarta, Google's email attribute is mapped to email attribute in MetaKarta.

MetaKarta logs the end user into the system and grants the protected resource to the user based on the end user's roles.

Signing in with Microsoft Azure Active Directory Web API

In this case the server at MetaKarta is the Resource Server, the Azure Active Directory (Azure AD) Web API is the Authorization Server, and the end user is the Client. The OAuth server configuration parameters look like the following:

The {tenant} value in the path of the request can be used to control who can sign into the application. The allowed values are tenant identifiers, for example, 8eaef023-2b34-4da1-9baa-8bc8c9d6a490 or contoso.onmicrosoft.com or common for tenant-independent tokens. The OAuth authentication workflow with Azure AD Web API is similar to the workflow with the Google Authorization Server.

Manage SAML2 Authentication

SAML (Security Assertion Mark-up Language) is an umbrella standard that covers federation, identity management and single sign-on (SSO) and single logout (SLO).

MetaKarta supports the SAML 2.0 protocol for external authentication.

SAML authentication requesters and responders communicate by exchanging messages. The mechanism to transport these messages is called a SAML binding. MetaKarta supports the following SAML bindings: HTTP redirect and HTTP POST.

Administrators can always login even in External Authentication Mode using the dedicated administrator rescue login URL: http://localhost:/MM/Auth?nativeLogin, where is the http port that MetaKarta responds to.

A misconfigured authentication scheme can result in user's being able to access portions of the application which should be restricted. This requires the Identity provider to sign the SAML response and/or assertion that it sends to the Service Provider (the application server). When configuring the SAML Server in the application server, set the Signature Element accordingly, i.e. Response, Assertion or Both:

At one time the product used to use the entire identity provider URL as an identifier of the SP (i.e. SP's entity id). However, with improvements for related SAML issues, it now uses only host name as the SP's entity id. Thus, you should now ensure that the audience restriction on the Okta server side should match the service provider's entity id. Otherwise, the application server will no longer authenticate using SAML OKTA.

SAML authentication requests sent from the service provider (i.e., the application server) to the IDP server and SAML responses sent from the IDP server to the service provider can be signed or unsigned, but not encrypted. However, SAML Logout requests sent from the service provider (i.e., the application server) to the IDP server are always signed.

https://www.metaintegration.com/MITI/Help/UserGuide/#!Documents/samlfaq.html

A sample decoded request:

{code:java}

<samlp:AuthnRequest
xmlns:samlp="urn:oasis:names:tc:SAML:2.0:protocol"

xmlns:saml="urn:oasis:names:tc:SAML:2.0:assertion"

ID="ONELOGIN_04d4bf69-4348-4148-b4bf-1f0d05a4802c"

Version="2.0" IssueInstant="2020-06-03T17:21:25Z"

Destination="https://dev-388428.oktapreview.com/app/nonedev388428_saml2test_1/exki10h88urLntvTj0h7/sso/saml"

ProtocolBinding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"

AssertionConsumerServiceURL="http://mitiauth.com:19980/MM/Auth">

<saml:Issuer>mitiauth.com</saml:Issuer>

<samlp:NameIDPolicy
Format="urn:oasis:names:tc:SAML:2.0:nameid-format:transient"
AllowCreate="true" />

</samlp:AuthnRequest>{code}

Frequently Asked Questions:

The value of NameIDPolicy in SAML request is "urn:oasis:namesSAML:2.0:nameid-format:transient"
The value of Issuer in SAML request is the host name portion of the unique id for the SAML identity provider which you specify in the SAML configuration as the Identity provider
The assertion consumer service URL is http://:/MM/Auth where server and port are the server and port number where the application server service is running.
The Service provider (entity id) is the host name where you are running the application server. We use that as the issuers in the SAML requested generated by the application server. Configure the app id and Audience restriction on the ADFS side accordingly.

Upon external authentication (SAML2), a valid user is created in the system (if not already there) based upon those credentials from the external authentication authority and will then be in MANAGE > Users. Thus, there is no need to import users in these external authentication scenarios.

Set SAML2 Authentication

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Select SAML from the Authentication pull-down.

Example

Sign in as Administrator.

Go to Tools > Administration > Users.

Select SAML from the Authentication pull-down.

Configure SAML Authentication

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Click Configure Authentication.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the banner.

Select SAML from the Authentication pull-down.

Click Configure Authentication.

MM does not use any Azure AD API to read the group assignments. All information about the user is extracted from the standard SAML response from AD FS, an IDP sits on top of the AD. If the user has created an attribute mapping for the GROUPS attribute and mapped group mappings from the external groups to the local groups, the external user will be automatically assigned a local group upon login.

# Configure the SAML server

In order to enable an external authentication server using the SAML2 protocol, the Administrator needs to configure the SAML server. The following example shows the Configure SAML Server editor parameters.

Steps

The user needs to obtain the following information about the Identity Provider (and Service Provider if the application server is behind a load balancer or proxy server.)

IDENTITY PROVIDER X509 CERTIFICATE: The URL of the IdP server
X509 CERTIFICATE: the public X509 certificate of the Identity Provider which allows MetaKarta to verify the signatures therefore establish trust in the messages that have been exchanged
SINGLE SIGN ON BINDING TYPE: The manner in which SSO binding is accomplished, either by redirect or POST.
SINGLE LOGOUT BINDING TYPE: The manner in which SLO binding is accomplished, either by redirect or POST.
SINGLE SIGN ON URL: the URL for single sign on.
SINGLE LOGOUT URL: the URL for single logout.

SAML Logout requests sent from the service provider (i.e., the application server) to the IDP server are always signed. Therefore a valid pair of SERVICE PROVIDER PRIVATE KEY and SERVICE PROVIDER X509 CERTIFICATE must be specified to support single logout.

SAML RESPONSE SIGNATURE ELEMENT: Whether the SAML authentication response message and SAML assertion are digitally signed by the Identity Provider or not.

The user may configure the SIGNATURE ELEMENT to be one of the following values: Response, Assertion, Both and Neither. MetaKarta will return an error message at the SAML user login time if an element is configured as signed but the element in the SAML response was not signed by the Identity Provider.

If an element is configured as not signed, MetaKarta will not validate the signature in that element even if it may have been signed by the Identity Provider.

IMPORT IDP METADATA: Allows the application server to read the identity provider's SAML metadata file which is an XML document that contains information necessary for interaction with the Identity Provider. This document contains the URLs of endpoints, information about supported bindings, identifiers and public keys. After parsing the SAML metadata file, the application server will automatically fill in the other fields from the values specified in the SAML metadata file. The user still needs to configure the Attribute Mappings and Group Mappings to complete the SAML Server configuration.
EXPORT SP METADATA: Allows you to export the SAML Server Provider metadata. The application server SP uses the protocol (http or https), server name and the port number that the browser uses to generate the endpoint URLs in the metadata. You may need to customize the SP auto-generated metadata file if it does not work as is.
SERVICE PROVIDER ENTITY ID: The host name of the service provider. If the MM application server is behind a loader balancer or proxy server, this should be the host name of the loader balancer or proxy server. We use that as the issuers in the SAML requests generated by the MM application server. Configure the app id and Audience restriction in the IdP server accordingly.
ASSERTION CONSUMER SERVICE URL: SAML protocol binding to be used when returning the SAML response from the IdP server if a proxy server or loader balancer is used on the SP side. This is used as the recipient or destination URL of the SAML responses. If the MM application server is behind a loader balancer or proxy server, the protocol, host name, and port in the URL should match those of the loader balancer or proxy server.
SERVICE PROVIDER PRIVATE KEY: the private key of the Service Provider. If both Service Provider's private key and X509 certificate are specified, the SAML authentication requests will be digitally signed by the application server service provider.
SERVICE PROVIDER X509 CERTIFICATE: the public X509 certificate of the Service Provider. If both Service Provider's private key and X509 certificate are specified, the SAML authentication requests will be digitally signed by the application server service provider.

# Configuring SAML with Microsoft Active Directory FS

AD FS is a service provided by Microsoft as a standard role for Windows Server that provides a web login using existing Active Directory credentials. Instructions for configuring and installing AD FS can be found at Microsoft AD FS website.

In your AD FS installation, please note the value for the 'SAML 2.0/W-Federation' URL in the AD FS Endpoints section. If you chose the defaults for the installation, this will be '/adfs/ls/'. Use this value for the Single Sign On URL in configuring the MetaKarta SAML Server.

The Identity Provider should take the value for the 'Identifier' URL in the AD FS Relying Party Trusts section.

The SAML server configuration sample parameters look like the following:

# Sample decoded response

Here is a sample decoded response in which both response and assertion are signed. We omitted the signatures in the sample. The Attribute statement in the assertion contains the user attributes First Name, Last Name, Login, Email, Full Name and Department.

<saml2p:Response xmlns:saml2p="urn:oasis:namesSAML:2.0:protocol" Destination="http://localhost:19980/MM/Auth"

ID="id137413689899007971127215705"

IssueInstant="2019-02-12T22:07:10.610Z" Version="2.0"

xmlns:xs="http://www.w3.org/2001/XMLSchema">

http://mitiauth.com:19980/MM/Auth

...

http://mitiauth.com:19980/MM/Auth

<ds:Signature

...

john.smith@metaintegration.com

http://localhost:19980/MM/Auth

urn:oasis:namesSAML:2.0classes:PasswordProtectedTransport

John

Smith

john.smith@metaintegration.com

john.smith@metaintegration.com

John Smith

Administrators

In configuring the SAML Server, one can use the following Attribute Mappings corresponding to the attributes received from the SAML response above.

The wildcard ("%") may be used when configuring group mappings.

The % matches zero or more characters.

In Okta, the user "Susan Smith" belongs to the groups Everyone and Developers.

After login via the SAML server on Okta, she is now a part of the Producers group:

SAML2 Authentication Workflow

Steps

A Client submits an authentication request via the User Interface of a Service Provider
To authenticate the Client, the Resource Server constructs a SAML Authentication Request, signs and optionally encrypts it, and sends it directly to the Identity Provider (IdP).
The Service Provider redirects the Client's browser to the IdP for authentication.
The IdP verifies the received SAML Authentication Request and if valid, presents a login form for the Client to enter his username and password.
Once the Client has successfully logged in, the IdP generates a SAML Assertion (also known as a SAML Token), which includes the Client identity (such as the username entered before) and sends it directly to the Service Provider.
The IdP redirects the Client back to the Service Provider
The Service Provider verifies the SAML Assertion, extracts the Client identity from it, assigns correct permissions for the Client and then logs him in to the service

MetaKarta does not have the private key of the Identity Provider. Therefore the SAML Assertion received by the MetaKarta can be signed but not encrypted. To validate the signature, MetaKarta only needs the Identity Provider's public key. However to decrypt the SAML Assertion, MetaKarta would need to have the Identity Provider's private key. Requiring the Assertion to be signed allows MetaKarta to verify that the assertion contents have not been altered in transit.

Similarly the SAML Authentication Request sent by Meta Integration® Metadata Management (MIMM) can be signed but not encrypted. MetaKarta uses the private key and X.509 certificate of the SP to sign the SAML Authentication Request.

A custom SAML application which Okta Single Sign ON URL is http://mitiauth.com:19980/MM/Auth, is created and configured in Okta. This application can be used as an Identity Provider to demonstrate the SAML authentication workflow. In this case the service at MM.com is the Service Provider, the custom SAML app configured in Okta is the Identity Provider, and the end user is the Client. The SAML server configuration parameters look like the following:

The User Attribute Mapping looks like below:

Steps

Following is the authentication workflow in MetaKarta:

An end user clicks on the "Login" button on a metadata management service at MetaKarta.
To authenticate the user, MetaKarta generates a SAML Authentication Request and redirects the user to the Okta Single Sign-On URL endpoint with the request embedded. This endpoint is unique for each application within each Okta tenant. Below is the Okta Single Sign-On login window.
Once the user is redirected to Okta they'll need to enter their Okta credentials, unless they had already authenticated into Okta in a previous session within the same browser. In either case, a successful authentication request will send a POST request to the MetaKarta Assertion Consumer Service, i.e. the MetaKarta Authentication Servlet, with an embedded SAML response from Okta. At a minimum, the response will:
- Indicate that it is indeed from Okta and hasn't been altered, and contain a digital signature proving such. This signature will be verified by MetaKarta using a public key from Okta that was previously stored in the SAML Server Configuration.
- Indicate that the user has authenticated successfully into Okta
- Indicate who the user is via the NameID, a standard attribute used in SAML assertions. Besides the NameID attribute, the response may also contain other attributes specified in the User Attribute Mapping. MetaKarta may retrieve the user information from these attributes..
After the assertion is successfully parsed and validated by the MetaKarta Authentication Servlet, the user will then be redirected to the MetaKarta default relay state, e.g., metadata explorer, which is usually the same page they would wind up if they were to simply log in with a username and password.

Go to the Group Assignment tab to auto-assign groups based upon the LDAP security model.

SAML2 single logout workflow

Steps

An end user clicks on the "Log out" button on a metadata management service at MM.
This MM terminates the MM user session and triggers SP-initiated SLO by sending a logout request to the IDP (Identity Provider)
Upon receiving a logout request, the IDP sends a Logout response to the SP that informs the SP whether SLO completed entirely or partially. Note that the IDP may trigger an IDP-initiated SLO to all other SPs that are part of the current session (SAML session) before sending the Logout response to the originating SP. MM currently does not response to the Logout request initiated by IDP.
This MM then redirect the user to the "logged out" page.

A MM session timeout due to inactivity will not trigger a SLO request to the IDP server.

Signing in with a custom SAML app configured in Okta

A custom SAML application which Okta Single Sign ON URL is http://mitiauth.com:19980/MM/Auth, is created and configured in Okta. This application can be used as an Identity Provider to demonstrate the SAML authentication workflow. In this case the service at MM.com is the Service Provider, the custom SAML app configured in Okta is the Identity Provider, and the end user is the Client. The SAML server configuration parameters look like the following:

The User Attribute Mapping looks like below:

Steps

Following is the authentication workflow in MetaKarta:

An end user clicks on the "Login" button on a metadata management service at MM.com.
To authenticate the user, MetaKarta generates a SAML Authentication Request and redirects the user to the Okta Single Sign-On URL endpoint with the request embedded. This endpoint is unique for each application within each Okta tenant. Below is the Okta Single Sign-On login window.
Once the user is redirected to Okta they'll need to enter their Okta credentials, unless they had already authenticated into Okta in a previous session within the same browser. In either case, a successful authentication request will send a POST request to the product's Assertion Consumer Service, i.e. the MetaKarta Authentication Servlet, with an embedded SAML response from Okta. At a minimum, the response will:
- Indicate that it is indeed from Okta and hasn't been altered, and contain a digital signature proving such. This signature will be verified by MetaKarta using a public key from Okta that was previously stored in the SAML Server Configuration.
- Indicate that the user has authenticated successfully into Okta
- Indicate who the user is via the NameID, a standard attribute used in SAML assertions. Besides the NameID attribute, the response may also contain other attributes specified in the User Attribute Mapping. MetaKarta may retrieve the user information from these attributes..
After the assertion is successfully parsed and validated by the this product's Authentication Servlet, the user will then be redirected to the this product's default relay state, e.g., MM Explorer, which is usually the same page they'd wind up if they'd simply logged into the MetaKarta with a username and password.

SAML FAQ

Here are some FAQ's about SAML Authentication:

Q: Is the product SAML 2.0 compliant?

A: Yes.

Q: Which SAML 2.0 profile is supported by target application - SP initiated SSO / IDP initiated SSO? ST preference is SP initiated SSO.

A: The product supports SP initiated SSO.

Q: Are SAML bindings based upon HTTP POST [ for IDP initiated SSO ] and HTTP Redirect/POST [ for SP initiated SSO ]?

A: Yes.

Q: Digital Signature from ST IDP: are X.509 Certificates issued by private CA is supported for digital signature of SAML messages/responses from ST IdP server (FIM)?

A: Yes.

Digital Signature from ST IDP: is it true that X.509 Certificate will be of type SHA2 (sha1 type of certificate is not accepted due to security policies)?

A: Yes. the product rejects signatures with deprecated algorithms (sha1).

Q: Digital Signature from ST IDP: is the Digital Signing Algorithm RSA SHA256?

A: The product supports several signing algorithms:

'http://www.w3.org/2000/09/xmldsig#rsa-sha1'
'http://www.w3.org/2000/09/xmldsig#dsa-sha1'
'http://www.w3.org/2001/04/xmldsig-more#rsa-sha256'
'http://www.w3.org/2001/04/xmldsig-more#rsa-sha384'
'http://www.w3.org/2001/04/xmldsig-more#rsa-sha512'

The default is rsa-sha256.

Q: Can the target system (Service Provider: SP) provide metadata xml file to provide SP configuration information?

A: A: Yes. There is an Export SP Metadata feature which allows the user to download the SP's metadata.xml which includes entity id, ACS URL, and X.509 certificate etc.

Q: Attribute contract: Which user attribute will be used for user identification in SAML assertion? e.g. email or Login name etc.

A: The product supports Attribute Mappings from the SAML attributes in the SAML assertion to user attributes. The login attribute can be mapped from any SAML attribute, e.g. email or login, as long as the attribute value is unique.

Q: Attribute contract: How the user identity should be passed in the SAML Token - as SAML Subject or SAML Attribute.

A: The user identity should be passed in the SAML response message as a SAML attribute.

Q: Attribute contract: What additional user attributes are required in SAML token and why? For e.g. Firstname, Lastname, Organization etc.

A: The only mandatory user attribute is the login (which can be mapped from a unique SAML attribute). The login is used as the user name. Other attributes, such as Full Name, Email, Distinguished Name, Groups or Description, are optional.

Q: Use of Digital Signature from SP (on SaaS side)?

A: Yes. The product's SP uses a X.509 certificate to sign the SAML authentication requests if the user has specified the private key and X509 certificate of the SP. If that is the case, the user needs to configure their Identify Provider server with the SP's X.509 certificate to verify the signature.

Q: Do you ensure SAML Authentication requests from SP are digitally signed by RSA SHA256 or RSA SHA384 or RSA SHA512 (SP will use its own X.509 certificate to sign)?

A: Yes. SAML Authentication requests from SP are digitally signed by RSA SHA256 using its private key and X.509 certificate.

https://www.metaintegration.com/MITI/Help/UserGuide/#!Documents/saml2authenticationworkflow1.html

User Attribute Mapping

The User Attribute Mapping tab specifies a mapping from the external user account attributes to MetaKarta user attributes (login, full name, email, etc.).

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Click Configure Authentication.
Go to the Attribute Mappings tab.

Example

Attribute mapping is only valid for LDAP, OAuth and SAML methods.

Sign in as Administrator and go to MANAGE > Users.

Click Configure Authentication and then the Attribute Mappings tab.

Choices of attributes may vary by authentication method enabled.

Custom User Attribute Mapping

One may define additional custom attributes for users in MANAGE > Metamodel. Once defined, you map map external user account attributes to these custom attributes.

Example

Here, we create First Name and Last Name as custom attributes on a User.

We then map the attributes as before.

Now, when that user logs in next, they see the new custom attributes populated:

Manage User Group Assignment

Users may be assigned to one or more groups, as defined in user group administration. Each group assigned controls roles assigned.

Native Group Assignment

Native group assignment may be used for all native users. It may also apply to other users (LDAP, OAuth, SAML) when automatic group assignment is not enabled, and thus when those other users are authenticated they will not have their group assignments reset.

In all these cases, any group assignments may be made as in the following steps.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Select the user from the list.
If you have not already done so create a new user.
If you have not already done so create a new group.
Click the Groups pull-down and choose the selected group to assign to the user.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the top banner.

Select the user to assign groups to, Stu.

Click the Groups pick list and choose the Business Users group.

Click outside the dialog and SAVE.

Explore Further

Define Administrative Users

Administrative users are those who are assigned to a group which is assigned the Global Administrator global role. To create an administrative user.

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Select the user from the list.
If you have not already done so create a new user.
Assign the role or group to the user.

Multiple Group Assignments

One may assign more than one group to a given user. In doing so:

The user then has the union of all security role assignments provided by those groups
If any of the groups are assigned to a particular configuration
Then whenever the user first signs in, they are presented with a choice of configurations from the union of all configurations the groups assigned have access to.
It is possible at this time or subsequent sign-ins to define a default configuration.
They may change configurations at any time by clicking on the configuration name in the header and select Change Configuration.
If none of the groups assigned to the user are assigned to a particular configuration
Then whenever the user first signs in, they are presented with a choice of configurations from the union of all configurations the groups assigned have access to, which is all.
It is possible at this time or subsequent sign-ins to define a default configuration.
They may change configurations at any time by clicking on the configuration name in the header and select Change Configuration.

Automated Group Assignment

It is common practice with LDAP, OAuth or SAML authentication to take leverage the information maintained about users in those systems, include organizational structure information, etc., and use this information to assign those users automatically on login to particular groups in the repository. In this way, there is no need to assign users to groups manually.

Once you enable automatic group assignment, every user authenticated by the external authority become a user in the system (if not already defined) and is assigned the proper groups each time they login. Thus, these users will lose any previous manual group assignment at the next login.

In some cases, whether using LDAP or other authentication, is to not depend upon these authentication modes to provide proper group assignment. This is because, those systems are managed by other authorities and are generally not maintained in order to group users so that group assignments logically map.

Instead, it is common to simply use the default group assignment, so that by default, any user is given the Guest group when logging the first time or when created. By default, Guest group is assigned to the Published configuration. In this way, one controls the default presentation to new users, and it is based on a controlled default configuration.

Once the user's true groups and responsibilities are identified, further groups are assigned to the user.

Automated LDAP Group Assignment

The LDAP configuration window offers a second tab for LDAP driven group assignment. In this case, the groups assignments may be associated to predefined LDAP groups or queries. There are two convenience features helping non LDAP experts retrieve/build the group assignments they need:

The LDAP group data entry allows one to search for groups defined in your LDAP environment and retrieve the exact LDAP query for such groups. This is very useful when planning to use large predefined groups of business users in group assignment.
The LDAP search filter data entry allows one to automatically build a proper query to create an LDAP based virtual group of users. This is very useful in creating small Administrator groups or temporarily groups for a project.

In order to create queries defining LDAP driven group assignment.

MetaKarta does not support nested groups, only direct group memberships. The reason for this limitation is there is no universal way to support nested groups across all types of LDAP servers. Although there is a specific way for Active Directory, it does not work properly in forests or when the query contains special characters, so it cannot be used this way either.

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Select LDAP Authentication from the Authentication type pull-down in the header.
Click on Authentication in the header and select LDAP.
Click on the Group Assignment tab.
Click on the Add icon.
Enter the following:
- Provide a Name for the query
- Define the group you wish to associate with users in the query

To assign groups by group name:

Click on the Browse icon in the Group entry
Enter a group name in the LDAP system or search text
Select the Distinguished Name for that group

To specify a search filter and include individual users

Specify a Search Root like: CN=company,CN=Users,DC=company,DC=local
Click on the Browse icon in the Search Filter entry and select users in that filter.

To specify a search filter and exclude individual users, you may

Specify a Search Root: CN=company,CN=Users,DC=company,DC=local
Use the following syntax: (&(!(sAMAccountName=username1))(!(sAMAccountName=username)))
Click OK.

Please keep in mind, when you create the first LDAP query for group assignment, you are now switching from native (manually managed) group assignment to LDAP driven (automatic) group assignment for all LDAP users. Any LDAP user will lose any previous native group assignment at the next login.

Similarly, when deleting the last LDAP query for group assignment, you are now switching from LDAP driven (automatic) group assignment, to native (manually managed) group assignment. Any LDAP user will now be only associated to the "Guest" group, until more groups are manually granted to that user.

Automated OAuth Group Assignment

See the details in OAuth Authentication.

In order to support automatic group assignment, specify in the Attribute Mapping tab the corresponding attribute for the security group in MetaKarta. If the attribute group in an OAuth user account information is to be mapped to the security group, the Attribute Mapping tab should look like this:

In this case, if the user account information for user John has a field called group , MetaKarta will use the value of the field group, e.g. "Business user", as the security group assignment for the user John.

The user account information is returned from the OAuth server to MetaKarta after the OAuth server validates an access token upon a login request.

You may also map individual values assigned to the OAuth attribute that maps to the Groups in MetaKarta.

Please keep in mind, when you populate an OAuth attribute for group assignment, you are now switching from native (manually managed) group assignment to OAuth driven (automatic) group assignment for all OAuth users. Any OAuth user will lose any previous native group assignment at the next login.

Similarly, when deleting the last OAuth attribute for group assignment, you are now switching from OAuth driven (automatic) group assignment, to native (manually managed) group assignment. Any OAuth user will now be only associated to the "Guest" group, until more groups are manually granted to that user.

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Click Configure Authentication.
Go to the Group Mappings tab.
Click the Add Assignment action icon.

Example

The wildcard ("%") may be used when configuring group mappings. The % matches zero or more characters.

Automated SAML Group Assignment

See the details in SAML Authentication.

Manage Concurrent Users

The MetaKarta license may include licensing for both named and floating concurrent users. E.g., if a license provides 10 named and 5 floating users, then up to 10 users may be set as named users and thus can always log in, and the rest of the users are considered floating, where only 5 can sign on concurrently.

Determining the Number of Users Available

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Click the user in the list.
Select the Named License checkbox to only look at named users.

Only available if named user licenses are enabled.

Click SAVE.

Assigning Concurrent (Floating) Users

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to
- MANAGE > Users in the banner.
- Click the user in the list.
Uncheck the Named License checkbox.

Only available if named user licenses are enabled.

Click Save.

Remember, all users not explicitly named are considered floating.

Setting User Inactivity Logout Duration

Steps

Sign in as a user with at least the Application Administrator capability global role assignment
Go to MANAGE > Users in the banner.
Click on the number of minutes of inactivity before logout.

User Statistics and Server Audit Log

All user logins, login attempts (rejected) and object creation/update/delete actions are recorded in a Server Audit Log..

Show Global Capabilities

You may determine all the global capabilities assigned to a user based upon global role assignments (either directly or via group assignments).

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Right-click a user and select Show Global Capabilities.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the top banner.

Right-click Stu and you have context menu options:

Select Show Global Capabilities:

Show Repository Responsibilities

You may determine all the object responsibilities assigned to a user based upon object role assignments (either directly or via group assignments) using this feature. This information is very useful when determining why a user does not have the ability to perform a task that you believe they should be able to and how to address it.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Right-click a user and select Show Customizations.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the top banner.

Right-click Ed and you have context menu options:

Select Show Repository Responsibilities:

Click SHOW Capabilities to see the responsibilities in terms of capabilities, rather than roles.

Show Consolidated Preferences

You may determine all the group preference assignments via group assignments.

Steps

Sign in as a user with at least the Security Administrator capability global role assignment.
Go to MANAGE > Users in the banner.
Right-click a user and select Show Consolidated Preferences.

Example

Sign in as an Administrator.

Go to MANAGE > Users in the top banner.

Right-click Stu and you have context menu options:

Select Show Consolidated Preferences:

Manage Users and Authentication

Listing All Users

Edit User Account Details

Review User Statistics

Edit User Preferences

Edit User Custom Attributes

Delete a User

Open User Profile

Show Customizations

Set the Maximum Number of Login Attempts

Set the Session Timeout

Import Users

Download Users and Statistics

Special Users

Manage Authentication

Manage Native Authentication

Set Native Authentication

Create a New Native User

Manage LDAP Authentication

Set LDAP Authentication

Configure LDAP Authentication

Create a New LDAP User

Manage OAuth Authentication

Set OAuth Authentication

Configure OAuth Authentication

# Configure the OAuth Server

# Add an External Authentication User

Request Headers

OAuth authentication workflow

Signing in with Google

Signing in with Microsoft Azure Active Directory Web API

Manage SAML2 Authentication

Set SAML2 Authentication

Configure SAML Authentication

# Configure the SAML server

# Configuring SAML with Microsoft Active Directory FS

# Sample decoded response

SAML2 Authentication Workflow

SAML2 single logout workflow

Signing in with a custom SAML app configured in Okta

SAML FAQ

User Attribute Mapping

Custom User Attribute Mapping

Manage User Group Assignment

Native Group Assignment

Explore Further

Define Administrative Users

Multiple Group Assignments

Automated Group Assignment

Automated LDAP Group Assignment

Automated OAuth Group Assignment

Automated SAML Group Assignment

Manage Concurrent Users

Determining the Number of Users Available

Assigning Concurrent (Floating) Users

Setting User Inactivity Logout Duration

User Statistics and Server Audit Log

Show Global Capabilities

Show Repository Responsibilities

Show Consolidated Preferences