The end of life (EOL) date for this module is on 31 January, 2020.
User Authentication
Users in the cluster configuration
Two example users are shipped as part of the default configuration:
auth {
enabled = true
users {
"user" {
password = "$2a$10$0/.uLmLRJoQS27UHSDE/eO6/oq.D.nmOEup1MNMBC60krmCkn6zYO" roles = ["ROLE_USER"]
}
"admin" {
password = "$2a$10$AwzXv3KE0kGIyaN5uWPwUOWraJQFWuJRZLxKjDdVpqM5GMChDZ4oW" roles = ["ROLE_USER", "ROLE_SUPERVISOR"]
}
}
}
Each entry under the users key corresponds to an individual username.
The password is stored as a BCrypt hash (using the Spring Security BCrypt implementation).
There is a convenience function to hash passwords embedded in the Open Access cluster node binary. Run the following from the node installation directory:
> java -cp "lib/*" com.itrsgroup.actor.auth.BCryptPasswordHasher <your_password>Each user is assigned roles which control what data they can see and which actions they can perform. See Data Permissions for more information.
Connecting with username and password
When authentication is enabled you will need to use a username and a password to establish a connection to the cluster. Username and password should be specified as parameters within the connection URL:
Connection conn = OpenAccess.connect("geneos.cluster://localhost:2551?username=user&password=password", connCallback, errorCallback);If authentication was not successful the error callback will be called with an error message.
Active Directory integration
The cluster can integrate directly with your existing Active Directory installation to validate user credentials.
This is simple to set up, requiring just the AD domain and AD server to use:
auth {
enabled = true
active_directory {
domain = "<my domain>" server = "ldap://<my ad server>" }
}
The roles for each user will correspond exactly to the Active Directory groups assigned to that user.
Custom Roles for Active Directory user
It is possible to set custom roles for a user authenticated using Active Directory:
active_directory {
domain = "<my domain>" server = "ldap://<my ad server>" custom_roles {
"oauser" = ["ROLE_USER", "ROLE_OTHER"]
"other" = ["ROLE_LIMITED"]
}
}
By default, these roles will be used instead of any groups the user has in the Active Directory. To combine both together, use:
active_directory {
...
combine_custom_roles = true
...
}
Combine authentication mechanisms
It is possible to configure the cluster to try one authentication mechanism and then fall back to another on failure. For example, to try the Active Directory first then the cluster user list:
auth {
enabled = true
order = ["active_directory", "users"]
users {
...
}
active_directory {
...
}
}