Velociraptor can be configured to use a single SSO provider using the usual configuration building wizard (see Here), but the wizard does not offer to configure multiple providers.
Sometimes we want to have multiple providers so we can allow users from another organization to be able to log into Velociraptor. To do this we need to configure the SSO authenticator manually in the configuration file.
velociraptor config generate -i and select the OAuth provider for the first provider. In the end your config file will have the following section where
oauth_client_secret refer to the Google OAuth app you created:
GUI: ... more settings ... authenticator: type: Google oauth_client_id: 12345.apps.googleusercontent.com oauth_client_secret: XYZ1234
To provide multiple authenticators, you will need to manually change to the
multi authenticator type:
GUI: ... more settings ... authenticator: type: multi sub_authenticators: - type: Google oauth_client_id: 12345.apps.googleusercontent.com oauth_client_secret: XYZ1234 - type: Github oauth_client_id: 123456 oauth_client_secret: 76521376523 - type: oidc oidc_issuer: https://accounts.google.com oidc_name: Rapid7 avatar: https://example.com/avatar.png oauth_client_id: XXXXX oauth_client_secret: AAAAA
Note that you can have multiple
OIDC authenticators and each can have a separate name and an icon associated with it (e.g. if multiple organizations use separate Okta logins).
Velociraptor will trust any of the configured authenticators, to identify the user and based on the username, grant the user the appropriate roles on the Velociraptor server. You will need to grant the user a role either through the command line:
velociraptor user add --role administrator firstname.lastname@example.org
Or via a notebook cell:
SELECT user_create(user="email@example.com", role="administrator") FROM scope()
Be aware that trusting multiple identity providers can result in account hijack if a user can get an account of the same name on another provider. Velociraptor just uses the account name provided by the OAuth provider to grant access and does not keep track of which provider actually identified the user.
In simple terms, if a user has username “mike” on
OIDC provider 1 and another user can get say a Github account for the user “mike”, then the second user can impersonate the first user by logging in with the second provider.