...
No. If you aren’t using LDAP, then Isora GRC will use its local database (with locally stored password hashes) to authenticate users, and no authorization or existence checks will be performed. If you are using Single Sign-On (SSO) without LDAP, then authentication (and possibly authorization) will be performed by your SSO provider.
How does Isora GRC typically use LDAP?
If you are using LDAP want to integrate LDAP with Isora GRC in your environment, then you should specify information about your LDAP or AD server to Salty Cloud as part of the on-boarding process, so your Isora GRC instance can be configured correctly to work with your server(s). Isora GRC will use a service account to communicate with the LDAP/AD server to perform the following activities:
Authentication- If you’re using LDAP but not Single Sign-on (SSO), then Isora GRC will use LDAP to authenticate users when they log in, unless they have a locally defined password. If a user has a locally defined password, then Isora GRC will not use LDAP to authenticate that user. When authentication checks are performed, Isora GRC will also verify that the user has any required attributes as specified when you configured your LDAP integration.
Authorization- For every request a user makes using Isora GRC, Isora GRC will contact the LDAP/AD server to verify that the user is authorized, based on the required attribute(s) you specified when you set up the LDAP integration. This is not fine-grained or role-based authorization. Isora GRC does not have detailed information about group memberships and other information which may be stored in your LDAP/AD server. The only role-based authorization done within Isora GRC is based on its own local database of users and permissions. Additionally, Isora GRC supports local service accounts- if you set up a user as a service account in Isora GRC, then all authorization checks on that user will be skipped.
Existence Checks- When you type the name of a user into Isora GRC (for example by specifying a person as the owner or IT Contact for a host in inventory, or as a delegate for answering org unit questions on a survey), if that user is not already defined locally in Isora GRC, then Isora GRC does a “people search” on the LDAP/AD server to check if that person exists.
Automatic User Account Provisioning- When you delegate a question or host, if you start typing the name or username of a user who exists in LDAP, but does not yet have an account in Isora GRC, you can automatically create a user account for them. The account will have basic information and it will not have any roles assigned automatically. This ONLY works if LDAP integration is set up correctly.
| Tip |
|---|
TIP: Authentication is checking if someone is who they say they are; Authorization is checking if someone is allowed to do something. |
...
Your Identity Provider (IDP) is probably still using LDAP/AD on the back-end to authenticate your users, but Isora GRC does not need to access the LDAP/AD server directly in order to use SSO. Isora GRC will use SSO to authenticate users, but without having access to the LDAP/AD server, Isora GRC will not perform any authorization or existence checks. What are the impacts?
Skipping “authorization and existence checks”- You won’t be able to limit which users can access Isora GRC based on LDAP attributes (such as group affiliations). Any user that has an account on Isora GRC will be able to log into the tool. As long as you are careful about which users you create accounts for, this shouldn’t be a problem.
Delegation- You will still be able to add new users to Isora GRC through delegation, but without verifying user information or doing typeahead searching. For example, if you want to delegate to “Bob Jenkins,” and his username is bobjenks but you type in “bobjenkins” (because you misremember his username), a new user account on Isora GRC will be created with username “bobjenkins.” But Bob Jenkins won’t be able to log in, because you’re using SSO, and his SSO username is actually “bobjenks.”
Local passwords ignored- If you use SSO to log in, even if the user has a password defined within Isora GRC, that password will be ignored for the purposes of logging in via SSO. The locally defined password does not have to match your SSO password.
I need help integrating my instance of Isora GRC with LDAP and/or SSO- what should I do?
...