- Can SSO be enabled alongside OAuth in Okera?
- Short answer: No. However, most SSO systems allow OAuth to be enabled.
- When a user logs into Okera, the Web UI uses the ODAS REST API to exchange the resulting OAuth token for an Okera token to gain access to the Okera Web UI.
- We accept OAuth’s thumbs up on “user” and generate an Okera token which only exists within ODAS. That’s separate from an SSO token that was generated elsewhere and which we may not be able to directly validate (in some configurations we can, in others we defer validation to an external service). If users want to integrate OAuth and SSO, they’d have to do that on their end and then expose it to use as one unified REST endpoint that we could call. The system for acquiring an SSO token from a customers' system is separate from the Okera tokens (which we generate).
- We have a feature on the CLI where users could configure their SSO endpoint so that our “dbcli get-token” just forwards the request to their endpoint, resulting in Okera stashing an SSO token. We could extend this to the GUI, where a properly configured ODAS cluster would have the user “login” to our GUI, but that would just forward the request to their SSO server. There would not be a connection between the Okera token and the SSO token, we’d just be using the SSO token across the board.
- This would require that the ODAS cluster to be configured to validate SSO tokens somehow (either via a public key that they provided to us or configured ODAS to use a REST endpoint for token validation)