Configure OpenID

Ribbon

Configure >  Security > Users > Accept OpenID Authentication

Configure >  Security > Users > Configure OpenID

OpenID URL

Enter the full path to the discovery URL of the OpenID server, minus the standard "/.well-known/openid-configuration" (this will be appended automatically).

Include the protocol (http:// or https://), and the port if running on a non-standard port (that is, not 80 or 443).

You should be able to copy the address with the "/.well-known/openid-configuration" appended and open it in a browser and see a text-based response.

Press the Test button now and click on 'Login with OpenID' to open a browser to the correct address. If the URL is incorrect or OpenID returns a malformed configuration response, an error message will display.

Client ID

OpenID needs to be configured with a client to allow Enterprise Architect to use its services. Enter the Client ID here.

Client Secret - (optional)

Some OpenID clients require a Client Secret to further secure the requests. If the client requires a secret, enter it here. It will be saved as an encrypted value.

Scope

Enter the OpenID scopes required to return a response with the required information. A scope of 'openid' is mandatory according to the standard. Other common scopes include 'profile' or 'email'.

Claim to Match to Local User

Enter the claim that will be returned when querying the OpenID 'user_info' that will be used to match the OpenID user to an existing model user login.

'Claims' are information fields that the OpenID server is claiming are true about the authenticated user. Most OpenID servers allow this to be customized so it can be set up to return a claim field specifically for use with Enterprise Architect, if desired.

Note: The only claim that is guaranteed to be unique for a user is 'sub'. This is the 'subject' of the claim. For new models this would be a good default setting in the claim field.

For existing models where there are already users in the model that should be matched to OpenID, it is recommended to use a 'username' field of some sort. Either the standard 'preferred_username', 'email' (if email is used, it is recommended that email validation is enabled) or a custom 'EA username' would make sense in this situation.

If using a claim other than 'sub' it is up to the maintainer of the OpenID server to ensure that the claim is unique and secure, and to ensure the claim can not be edited by the user.

Claim to Match to Local Groups

This option is used if the additional setting 'Automatically create or modify Windows or OpenID users' is enabled. It is not used otherwise. See the Single Sign-On (SSO) Options Help topic.

Enter the claim that will be returned when querying the OpenID 'user_info' that will be used to match the OpenID user's groups to existing model groups.

'Claims' are information fields that the OpenID server is claiming are true about the authenticated user. Most OpenID servers allow this to be customized so it can be set up to return a claim field specifically for use with Enterprise Architect, if desired.

The OpenID standard does specify anything in regards to user groups. Some OpenID servers have this functionality built in but still need to be enabled so the groups can be returned in the 'user_info'. The returned groups can be either a single JSON field or a JSON array containing multiple group names.