User management in GGCE
The original GG maintains a separate user (SysUser
, WebUser
) database and GGCE adds OAuthClient
to this list. Users may be organized into groups (SysGroup
). User authentication and password management is handled by GG, GGCE adds OAuth token support.
In enterprise deployments, user management and authentication is generally managed centrally, either through AD or another identity management solution. GGCE is primarily a resource server and should therefore be designed primarily for use with external identity auth servers such as https://www.keycloak.org, Okta, Azure AD and others.
For development or evaluation deployments, GGCE should provide a built-in auth server (spring-security-oauth2-authorization-server
?) that only handles LOCAL
accounts.
GGCE as a resource server then needs to support multiple auth servers: e.g. keycloak + built-in, or perhaps azuread + google + okta + built-in.
Support for CT
The CT uses SOAP and passes user credentials with every SOAP request. Without changing the bulk of CT and the current GG webservices, the initial idea is to use a user-definable application password that is used for legacy applications.
User provisioning
GGCE requires that user info is stored in the local database (SysUser
). This is used in auditing info across the database.
SCIM or periodic updating can be used to synchronize the local "user database" with external IdP. But at the very least, a user may be denied access to the system as IdP will not issue a token for disabled accounts.
Permission and role management
Permission management (ACL) remains within the domain of the application and permissions must be configurable in GGCE directly.
Logging into GGCE
Since the API is only a resource server, access is only possible with a valid JWT token provided by one of the configured auth servers.
The login screens of GGCE Web and of GGCE Server should therefore include the all configured login options:
- Login with Microsoft
- Login with Google
- Login with...
- Local login (GGCE Auth Server)
Each one of these redirects the user to the respective "login page" and ideally results in a valid JWT for the application.
Obtaining a GGCE token
The API should consider JWT from any of the configured IdP as valid, but we may want to exchange the external JWT for a GGCE-generated JWT (enhance it with SysUser
data) after login.
Similarly, we should have a single "login screen" as described above, implemented in GGCE Server.