First off, whatever authn you use for Grouper UI and WS will still be available. i.e. if you are shib and LDAP WS authn, then most of this wont apply to you (only the section on restricting source IP address)... However...
We need a better built-in WS authentication method than basic auth
- Passwords not stored in clear text in tomcat-users
- Passwords not transmitted on the wire
- We need something not tomcat specific
- Tomcat config files are painful to automate the use/removal of
- Ability to filter the source address for WS
We need easier quick starts and bootstraps in UI/WS
Password table in Grouper: grouper_password
Note, even if Grouper is not doing authn, it could still restrict the source address. For WS, any authns would get a record inserted or updated here
| Column | Type | Description |
|---|---|---|
| id | varchar | uuid of this entry (one user could have ui and ws credential) |
| username | varchar | username or local entity system name |
| type | varchar | username or localEntity |
| is_hashed | varchar | T for is hashed, F for is public key |
| encryption_type | varchar | e.g. SHA-256 or RS-256 (key type) |
| the_salt | varchar | secure random prepended to hashed pass |
| the_password | varchar | encrypted public key or encrypted hashed salted password |
| ws_or_ui | varchar | ws (includes scim) or ui |
| allowed_from_cidrs | varchar | network cidrs where credential is allowed from |
| recent_source_addresses | varcahr | json with timestamps |
| failed_source_addresses | varchar | if restricted by cidr, this was failed IPs (json with timestamp?) |
| last_authenticated | timestamp | when last authenticated |
| last_edited | timestamp | when this was last edited |
JWT table recently used in Grouper: grouper_password_recently_used
A process would clean these out after the configured drift (10 minutes)
| Column | Type | Description |
|---|---|---|
| id | varchar | uuid of this entry (sent from client) |
| millis_since_1970 | integer | millis since 1970 that this was used |
Manage passwords
UI for admins to set a user's (or local entity's) UI password or could restrict source IP cidrs. UI passwords would need to follow strength rules
UI for admins or end users (self serve) to download a new generated WS private key or password for a local entity they can ADMIN or restrict source IP cidrs
- Someone who can create in a folder (and optionally in a group who can create WS credentials)
- Create a local entity
- Download its password or private key (can only download once)
- Grant privs to the local entity
- Use it in WS calls
Admins and end users can not view or re-download passwords or private keys
Basic authn built in to Grouper
If configured (for quick start only), the UI could use basic auth and use passwords configured for users
Its possible users could reset their password using their old password to authenticate.
Passwords for WS
Your LDAP or Kerberos or apache or tomcat authn would still work. Its possible there could be multiple allowed... i.e. to transition into local entity JWT authn. Depending on configuration.
Private key signed JWT would be recommended with WS, or required at some sites. Source IP's could be required too
- Username is the system name of the local entity
- Private key is a generated by Grouper and downloaded once
- This is not sent across the wire in WS calls
JWT details
- To authenticate with JWT the client would
- Generate a uuid
- Have the correct time within configured drift (10 minutes?), get the millis since 1970 (GMT)
Send a "Bearer" authorization header sfdlh23kjh.kjhsdfkjhsf.kjh345kjhkjh (three parts separated by dot)
First part is the header is base64 url encoded
{ alg: "RS-256", typ: "JWT" }The second part is what makes the token unique and identifies the user
- uuid is a unique uuid per request, cannot be re-used
- username is: system name of local entity
- millisSince1970: Number of millis since 1970, the timestamp received on server needs to be within the drift
{ uuid: "abc123", username: "org:businessSchool:credentials:wiki", millisSince1970: 1234567 }
- Thus the same request cannot be replayed