Generating password via source password policy in Cloud Rule

Identity Security Cloud (ISC) ISC Discussion and Questions
,
1

Does anyone have working Beanshell code which generates, or validates, a password using a PasswordPolicy? (This will be in a BeforeProvisioning Rule). I can find various snippets in the preloaded Cloud rules, but it’s not clear to me if these will work for my purposes, and since this is a Cloud rule requiring SailPoint review, trial-and-error is not a good option.

For example I see this, but I’m not sure I can use this in the context of a BeforeProvisioning rule and these classes are not exposed in documentation:

import sailpoint.thunderbolt.service.ConnectorService;
import sailpoint.thunderbolt.service.module.ServiceModule;

ConnectorService connectorService = ServiceModule.getService(ConnectorService.class);
Field f = new Field();
return connectorService.generatePasswordBasedOnPolicy(context, application, identity, field);

I also see various snippets which use PasswordPolice to validate a password (also not in the java docs). This would also work for my purposes as I can generate the password randomly (not within policy) in a loop until it successfully validates against the application password policy:

PasswordPolice pp = new PasswordPolice(context);
 pp.checkPassword(null, value, false);

Hoping that someone has already figured out the right methods to use! Please advise – thank you.

1 Like
2

I haven’t seen any implementation of generating password using Password Policy yet.

I haven’t seen this thunderbolt, where did you find them ?

Usage of context is prohibited in IDN, are you replicating password implementation from IIQ in IDN ?

AFAIK, Password policies help us to validate the password when user set it.

In Implementation, we generate password with required standards using a Transform in Create Account Provisioning Policy form.

1 Like
3

@MVKR7T – thank you greatly for your response.

The first snippet, including thunderbolt classes and use of context variable, I found in the AttributeGenerator Rule named “Create Password” which is returned in the list of Cloud rules when I call {{baseUrl}}//cc/api/rule/list.

The documentation on code restrictions for Cloud Rules is ambiguous as to whether the context variable itself is disallowed or only SailPointContext methods. If the context variable itself is banned then the list of blocked code fragments should be updated to include “context” instead of “context.”. But as I mentioned it’s used in that SailPoint-provided Cloud Rule.

I do have working IdentityIQ code which generates a password via PasswordPolicy, but this does use SailPointContext methods so I am aware it cannot be ported over into IdentityNow. I was hoping to find something equivalent maybe using IDNRuleUtil.

I am further led to believe this might be possible because the SailPoint-provided Standard Services IdentityNow BeforeProvisioning Rule includes a scramblePassword method with the following code:

		for (count = 0; count < 18; count++) {
			index = rnd.nextInt(len);
			newPassword += charset.charAt(index);
		}
accountRequest.add(new AttributeRequest(attribute, ProvisioningPlan.Operation.Set, newPassword));
**//TODO: Update to use PasswordGenerator**

Thank you!

4

Someone might have deployed that Rule in cloud through SailPoint expert services, but it is strange that it got deployed, there might be some background story behind this.

Context or SailPointContext, not available in IDN.

I couldn’t find this code. Anyway, you can generate the password on your own and set in account request, that is fine. But the question is generating password using Password policy is not there yet.

You can generate password completely using your code in Before Provisioning Rule or using Transform as per your standards.

5

@colin_mckibben @colin_mckibben Alex and myself are very curious on this topic. Any way you guys can get us an answer from expert services/engineering/whoever is needed for this? In my mind, using the referenced policy on the source/application via sailpoint.api.PasswordGenerator would be the most appropriate way to go about this, so being able to pass context should be allowed in this situation. This way we avoid generating a random password ourselves that could not be policy requirements, or become outdated if the policy on the source becomes more advanced.

6

Hey @patrickboston @AlexFKing ,

I talked with our team and you would be able to generate a password in a before provisioning rule like so, passing the context to the constructor. (We allow context to be passed in, just not used on its own, think context.methodName())

PasswordGenerator passwordGenerator = new PasswordGenerator(context);
String newPassword = passwordGenerator.generatePassword(identity, application);

With that being said @AlexFKing the rule you found when calling /cc/api/rule/list is the better option here, it will do the same thing without having to write a beforeProvisioning rule.

Using it in a create provisioning policy would look like adding a new field for your password and calling the rule from the rule transform operation.

For this to work you have to set up the password policy and enable it in the source

{
  "name": "Account",
  "description": null,
  "usageType": "CREATE",
  "fields": [
    {
      "name": "password",
      "transform": {
        "type": "rule",
        "attributes": {
          "name": "Create Password"
        }
      },
      "attributes": {},
      "isRequired": false,
      "type": "string",
      "isMultiValued": false
    }
  ]
}

The Create Password rule calls the methods you originally found:

ConnectorService connectorService = ServiceModule.getService(ConnectorService.class);
return connectorService.generatePasswordBasedOnPolicy(context, application, identity, field);

I would also like to ask, if you must do this in a before provisioning rule what is the use case?

2 Likes
7

@tyler_mairose thank you for the confirmation that context can be passed in as a variable.

The use case we are implementing, is setting an AD account with a random password during the Leaver workflow. The BeforeProvisioning rule I wrote to achieve this is based on the SailPoint-provided Standard Services IdentityNow BeforeProvisioning Rule, which includes a “scramblePassword” method that creates an AttributeRequest to set a randomly-generated password. We cannot achieve this via Disable ProvisioningPolicy because we do not want this for all disables. We are also aware that this could be done via the AD PowerShell BeforeProvisioning Rule but opted for the Cloud BeforeProvisioning rule.

I was able (before seeing your response) to get this working by using PasswordPolice to validate randomly generated strings against the application PasswordPolicy (and regenerating if validation fails). Thank you for providing the PasswordGenerator code as that will obviously be a more elegant approach.

8

@AlexFKing No problem!

I was thinking more about your use case and it sounds like you want to change a users password if they are leaving they company and a certain criteria is met.

I understand you have something working but I am wondering what the logic is to determine if the account needs the password reset and if it is something that can be pulled in a transform during the account disable. If so you could write a conditional transform checking that condition and return the right response for each case. This is what I am thinking:

{
    "name": "Account",
    "description": null,
    "usageType": "DISABLE",
    "fields": [
        {
            "name": "password",
            "transform": {
                "type": "conditional",
                "attributes": {
                    "expression": "$lifecycleState = 'terminated'",
                    "positiveCondition": "$newPassword",
                    "negativeCondition": "$current",
                    "newPassword": {
                        "type":"rule",
                        "attributes": {
                            "name": "Create Password"
                        }
                    }
                }
            },
            "attributes": {},
            "isRequired": false,
            "type": "string",
            "isMultiValued": false
        }
    ]
}

Trying to save you from having to maintain a cloud rule :smile:

2 Likes
9

@tyler_mairose the use case here is to reset the AD account’s password after a delay to ensure there are no mistakes in the identity’s termination before we go removing all of their access and changing their password. Because of this, we cannot just use a disable policy unfortunately.

I do have another question from this conversation though. As Alex pointed out, there are some OOTB rules being used that utilize classes from this sailpoint.thunderbolt package. This does not appear to be available in the current IDN JavaDocs today, however, these seem like some very useful utility classes. I have another use case where I need to check if there may be an old stale AD account laying around from previous employment that we could correlate to an identity as opposed to creating a new AD account which will happen from Birthright Role Assignments. Since real-time processing occurs, an account may get created in situations where we may be able to find these old accounts and correlate them, resulting in more than one account. I am thinking these sailpoint.thunderbolt.* classes have more utilities for querying an LDAP and potentially aggregating a single account in something like a BeforeProvisioning rule. Is there any way these classes can be exposed to us since they are being used in OOTB rules?

1 Like
10

We have established an assumption that whenever a specific AD_GLOBAL_BIRTHRIGHT group is removed, we want to set a new random password. So the removal of that entitlement is the trigger we are using.

So following your approach, we could potentially use a MODIFY provisioning policy, and check whether the user has that group assigned. At the time that the group is being removed, however, I think the data available to the transform will still show it being assigned on the account, so the password would not change until there were another subsequent modify request.

Let me know if you can think of a way to avoid the Cloud Rule given this additional use case information. As you said, I do have a working Cloud Rule that I am comfortable with, but find all of your ideas very useful in developing my solutioning mindset for IDN, coming from an IIQ-heavy background. Need as many tricks in my toolset as I can get!

11

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.