Authentication:
Authentication is the act of establishing a user’s identity within an application. In the context of IdentityIQ (IIQ). This is the process of the web application establishing a user’s identity through one or more methods. This process, in conjunction with authorization, controls access to the IIQ application. In order To validate someone is authorized, an authentication source needs to be checked against.
Authentication Mechanisms:
The system administrator can configure the type of mechanism by which IdentityIQ authenticates users.
In general, there are three fundamental mechanisms we have in SailPoint IIQ:
- Internal IdentityIQ authentication (default)
- Pass-Through Authentication (PTA) Configuration
- Single Sign-On (SSO) Configuration
Now, let’s talk about the Single Sign-On (SSO) Configuration using rule.
Sign-On (SSO) Configuration By Rule:
In this document, I am going to explain how we can achieve a single sign-on when you cannot use SAML, meaning when you have a restriction that you can’t use SAML.
SailPoint has given an option to configure the SSO when we don’t have SAML by using a rule called Single Sign-On Rule.
To enable this SSO configuration in IIQ, go to the global settings → Login Configuration → SSO Configuration → Enable Rule Based Single Sign-On (SSO)
In this, you can write two rules for SSO. The first one is the Single Sign On rule, which has SSOAuthentication object type. And it will return a SailPointObject (Identity or LInk). This rule specifies how the user is authenticated and how to match Identity for SSO in IIQ.
When this rule is implemented, the SailPoint IIQ assumes that there is unique information about the identity who is going to login that will be present in the Http Request. This information is present in the header or body of the Http request.
The below rule will help us to do this.
import sailpoint.object.Identity;
import sailpoint.object.Link;
import sailpoint.tools.GeneralException;
import sailpoint.api.SailPointContext;
import javax.servlet.http.HttpServletRequest;
import javax.servlet.http.HttpSession;
import java.util.*;
String userID = null;
Identity identityObj = null;
log.error("Entering into SSO IIQ Rule");
try
{
userID = httpRequest.getHeader("USERID");
}
catch (GeneralException e)
{
log.error("USERID in the header");
}
if (userID == null)
{
log.error("userID is null");
}
else
{
log.error("userID is = " + userID);
// Get IIQ ID associated with SSO identityObj
identityObj = context.getObjectByName(Identity.class, userID);
if (identityObj == null)
{
log.error("SSO ID not found for Employee = " + userID);
}
else
{
log.error("SSO validated for Employee = " + userID);
}
log.error("usernname "+identityObj.getName());
}
log.error("Exit from SSO IIQ Rule");
return identityObj;
This rule is very straight forward in that I am getting USERID from httpRequest. Checking if it is null or not. If not, then get the identity object for the user and return it.
Now, save it.
The second rule is optional. The validation rule is mainly for validating the request. It runs on every page change as the user navigates through IIQ. It validates the session with the SSO provider by getting the headers and body through Http Request. It is for verification of those clients for extraordinary constraints for security. But it can impact the system’s performance. If the rule finds that this is not a valid session, then it logs out, and the user will throw an error. For now, we are not using it.
Now, we will do testing for how it works.
I am using the Postman application (REST client) as an SSO provider, which sends the HTTP request, and for the request there should be a header with certain values that should be sent to SailPoint IIQ.
I am sending the name of the user (Aaron.Nichols) as USERID in the body and just trying to find out the identity requests of the user.
Just hit the Send button.
This Postman application acts as the SSO provider. Once I hit the Send button, it will try to fetch the identity requests of the users if the user is presented in IIQ (it will try to login as Aaron.Nichols). This is just a sample workaround. You might not see the exact IIQ page in the Postman. But you can check the status as 200 and check in the Preview section.
You can also check in Pretty.
You can also check in the Logs.
Let’s test in negative that providing wrong details
IIQ is erroring out simply because of an invalid user.
You can check the logs as well.
I hope you understood and liked it.
This is one of the examples I have given for using a rule for SSO. In real-time scenarios, it might be something different, like we have SSO service providers, by which we can do. But the approach is the same behind the concept. Happy learning.