Shared Security Reference Data

When deciding which Table Groups of the centralized repository each individual repository should share, the Security related tables should be carefully considered, and the decisions based on a number of factors:

• How are users going to be validated - via an external Single Sign-On (SSO) mechanism (like OpenID or Windows NTLM) or via a simple User ID and password stored within the Enterprise Architect repository?
• Should all repositories share the same list of users?
• Should user passwords be synchronized across all repositories?
• Do all users have the same permissions across all repositories?

There are two Shared Table Groups related to Security:  1) 'Security Users and Groups' and  2) 'Security Permissions'. Whether a repository should be configured to share either or both of these Table Groups depends on the environment. Consider these scenarios:

Scenario 1. All repositories have the same Users, and all Users have the same permissions within the Repositories; the individual repository should share both Table Groups: 'Security Users and Groups' and 'Security Permissions' from the centralized repository.  The user list and permissions will need to be managed within the centralized repository.

Scenario 2. All repositories have the same users, but the Users have different permissions across the Repositories; the individual repository should share the Table Groups: 'Security Users and Groups' from the centralized repository.  The user list will need to be managed within the centralized repository while the user permissions will need to be managed within the individual repositories.

With each of the above scenarios it is still a requirement that the passwords for Users are maintain within the individual repositories; the only way to avoid this is to implement SSO authentication or to use Pro Cloud Server's Global Authentication.

Authentication via SSO

When using an SSO authentication mechanism, Enterprise Architect is no longer responsible for determining if the entered user credentials are valid, instead it is OpenID or Windows NTLM that validates the user credentials and advises Enterprise Architect that the given user is valid.  Enterprise Architect then uses the supplied UserID to determine what features are available within the current repository.  This requires that the complete list of Users is defined within the repository, however if each individual repository is configured to share the Security related reference data the list of Users (and their permissions) can be defined and managed in the centralized repository.

Authentication via Global Authentication

It's possible to configure the Ports of the Pro Cloud Server to use a 'Global' repository for  authentication purposes.  When this option is set the initial log in process uses the 'Global' repository to validate the supplied user credentials, once those credentials have been confirmed any further security related queries use the information saved in the current repository.  The benefit of this configuration means that each repository has the ability for the same user to have different permissions in each repository.  However the downside is that the security user definitions must be manually kept up-to-date in each repository.

Using Shared Repository data (as described in the topic Link Reference Data to a Shared Repository) it is possible to remove the duplicated data by choosing certain Table Groups to shared and the remaining to be stored locally, the exact configure will depend on the individual environment.