Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

Do I have to use LDAP with Isora GRC?

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.

How does Isora GRC typically use LDAP?

If you are using LDAP 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:

  1. 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.

  2. 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.

  3. 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.

TIP: Authentication is checking if someone is who they say they are; Authorization is checking if someone is allowed to do something.

When you configure Isora GRC for LDAP integration, you will provide details about your LDAP/AD server(s), including login information for Isora GRC’s service account(s), the hostname or IP addresses of the LDAP/AD server(s) and ports used, and attribute:value pairs for any attributes that you want to require to authorize users to use Isora GRC.

How does LDAP relate to Single Sign-On (SSO)?

If your instance of Isora GRC is configured to use SSO, then Isora GRC won’t need to talk to the LDAP server to perform authentication. Instead, it will talk to your Identity Provider (IDP). Either way, Isora GRC will still use the LDAP server for authorization and existence checks.

What if I configure Isora GRC to use Single Sign-On (SSO) but not LDAP?

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?

  1. 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.

  2. 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.”

  3. 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?

Reach out to support@saltycloud.com and our support team will guide you through the process. This will involve gathering some information from you, sending you some info, and doing some customization on your instance of Isora GRC. For more info, see Isora GRC Customization .

  • No labels