Can we provide admin access in IDN based on time?

[Amrit1897 (Amrit Raj)]

Can we provide admin access in IDN based on time?
For e.g.: After certain time access should go.

[sunnyajmera]

I don’t think you can do OOTB.

[coelhoya2 (Yan Coelho)]

You can do a loopback connector and set expiration date when you do a access request but will be based on date and not time!

[baoussounda (Ousmane N'DIAYE)]

I have the same proposition. You can create a loop back connector to manage IdentityNow access rights and use expiration date option.

[ksbagade (Kartik Bagade)]

Hi @Amrit1897,

From my understanding, you would like to grant and revoke IdentityNow Admin rights based off a time schedule.

This can be done (albeit not OOTB) using Workflows:

• The trigger would be Scheduled Trigger (this allows for time input as well as custom CRON expressions) and would be set either for daily or for specific week days
• You would require 2 workflows - one to grant access during “work hours”, and one to revoke access for “after hours”
• The IDN Loopback connector would hold the Admin rights as entitlements to manage access for each entitlement

I haven’t tested it out yet but definitely sounds like an interesting use case.

Hope this helps!

[Amrit1897 (Amrit Raj)]

I have worked with loopback connector in IIQ but can’t see any it IDN.
https://community.sailpoint.com/t5/IdentityNow-Connectors/IdentityNow-Connectors/ta-p/80019

[coelhoya2 (Yan Coelho)]

You have 2 options deploy a custom connector made by Sailpoint(GitHub - sailpoint-oss/colab-saas-conn-identitynow-management: Loopback connector to manage IdentityNow like any other managed system. Allows to manage user levels, governance groups and identity status.) or made one creating a WebServices Source.
I receive some errors when deploying the sailpoint connector so o choose to do with WebServices:
base config:

https Operations:

"connectionParameters": [
            {
              "contextUrl": "/v3/public-identities",
              "httpMethodType": "GET",
              "pagingInitialOffset": 0,
              "pagingSize": 50,
              "sequenceNumberForEndpoint": "1",
              "uniqueNameForEndPoint": "TestConnection",
              "curlEnabled": false,
              "header": {
                "Accept": "application/json"
              },
              "operationType": "Test Connection",
              "body": {
                "bodyFormData": null,
                "jsonBody": null,
                "bodyFormat": "raw"
              }
            },
            {
              "httpMethodType": "GET",
              "pagingInitialOffset": 0,
              "sequenceNumberForEndpoint": "2",
              "uniqueNameForEndPoint": "GetAccounts",
              "rootPath": "$.[*]",
              "body": {
                "bodyFormData": null,
                "jsonBody": null,
                "bodyFormat": "raw"
              },
              "paginationSteps": "$sysparm_limit$ = 250\nTERMINATE_IF $RECORDS_COUNT$ < 1\n$sysparm_offset$ = $sysparm_offset$ + $sysparm_limit$\n$endpoint.fullUrl$ = $application.baseUrl$ + \"/beta/identities?limit=250&offset=\" + $sysparm_offset$",
              "responseCode": [
                "2**"
              ],
              "resMappingObj": {
                "id": "id"
              },
              "contextUrl": "/beta/identities?limit=250&offset=0",
              "pagingSize": 250,
              "curlEnabled": false,
              "operationType": "Account Aggregation"
            },
            {
              "resMappingObj": {
                "uid": "uid",
                "displayName": "displayName",
                "roles": "capabilities.[*]",
                "name": "name",
                "alias": "alias",
                "email": "email"
              },
              "contextUrl": "/v3/auth-users/$response.id$",
              "httpMethodType": "GET",
              "pagingInitialOffset": 0,
              "pagingSize": 50,
              "sequenceNumberForEndpoint": "3",
              "uniqueNameForEndPoint": "Aggregation By Id",
              "curlEnabled": false,
              "operationType": "Account Aggregation",
              "body": {
                "bodyFormData": null,
                "jsonBody": null,
                "bodyFormat": "raw"
              },
              "responseCode": [
                "2**"
              ],
              "parentEndpointName": "GetAccounts"
            },
            {
              "resMappingObj": {
                "displayName": "displayName",
                "name": "name",
                "description": "description",
                "value": "value"
              },
              "contextUrl": "/v3/search?offset=0&limit=50&count=true",
              "httpMethodType": "POST",
              "pagingInitialOffset": 0,
              "pagingSize": 50,
              "sequenceNumberForEndpoint": "4",
              "uniqueNameForEndPoint": "Role Aggregation",
              "curlEnabled": false,
              "operationType": "Group Aggregation",
              "rootPath": "$.[*]",
              "body": {
                "bodyFormData": null,
                "jsonBody": "{\"query\":{\"query\":\"source.name.exact:IdentityNow AND attribute:assignedGroups\"},\"indices\":[\"entitlements\"],\"includeNested\":false,\"sort\":[\"source.name\"]}",
                "bodyFormat": "raw"
              },
              "responseCode": [
                "2**"
              ]
            },
            {
              "contextUrl": "/v3/auth-users/$plan.nativeIdentity$",
              "httpMethodType": "PATCH",
              "pagingInitialOffset": 0,
              "pagingSize": 50,
              "sequenceNumberForEndpoint": "5",
              "uniqueNameForEndPoint": "Add Role",
              "curlEnabled": false,
              "header": {
                "Content-Type": "application/json-patch+json"
              },
              "operationType": "Add Entitlement",
              "body": {
                "bodyFormData": null,
                "jsonBody": "[\n  {\n    \"op\": \"replace\",\n    \"path\": \"/capabilities\",\n    \"value\": [\"$plan.roles$\"]\n  }\n]",
                "bodyFormat": "raw"
              },
              "responseCode": [
                "2**"
              ]
            },
            {
              "contextUrl": "/v3/auth-users/$plan.nativeIdentity$",
              "httpMethodType": "PATCH",
              "pagingInitialOffset": 0,
              "pagingSize": 50,
              "sequenceNumberForEndpoint": "6",
              "uniqueNameForEndPoint": "Remove Entitlement",
              "curlEnabled": false,
              "header": {
                "Content-Type": "application/json-patch+json"
              },
              "operationType": "Remove Entitlement",
              "body": {
                "bodyFormData": null,
                "jsonBody": "[\n  {\n    \"op\": \"remove\",\n    \"path\": \"/capabilities\",\n    \"value\": [\"$plan.roles$\"]\n  }\n]",
                "bodyFormat": "raw"
              },
              "responseCode": [
                "2**"
              ]
            }
          ]

The only problem is with the Patch Role, this connector do not append Roles and when revoking it will revoke all roles and the user will return to be a normal User.

Let me know if works for you!

[colin_mckibben]

Another option could be to leverage Roles, Forms, and Workflows.

You could setup a special role called “Temporary Admin Access”. It won’t have any entitlements, and it should be set to be requestable in Request Center with the appropriate approval chain if needed.

Then, create a workflow that listens for Access Request Decision with a filter that will only trigger when that specific role is requested and it has been approved. You can send a form to the requester asking for additional details, like why they need the admin access and how long they need it for. The workflow will wait for the form to be submitted, and then you can send another form to the appropriate approver (ex. the identity’s manager or another IDN admin) for them to sign off on the request.

Once the form has been submitted, the workflow can then use the update auth user endpoint to assign the ORG_ADMIN user level to the identity. Finally, the workflow will use the Wait action to wait until the specified end date based on the form the identity submitted. Once the end date is reached, the workflow will continue where it left off and use the update auth user endpoint to remove ORG_ADMIN from the identity.

This is such a juicy use case that I’m going to work this into my Advanced Workflows presentation at this year’s Developer Days. I’ll also post a blog post (Blog Posts) about this with the workflow code once I finish it.

[jrossicare (Jason Ross)]

This is great, thanks for posting it. I currently use the Loopback connector, so need to update it to this one

[uday_kilambiCTS (Uday Kilambi)]

@colin_mckibben - Nice workaround. I am liking these possibilities with workflows, looking forward for your demonstration for advanced use cases.

[colin_mckibben]

I have written a blog post and workflow template for making this use case work. You can check it out here.

Temporary Admin Access in Identity Security Cloud using Roles, Forms, and Workflows

[Tutorials-Blue] If you ever find yourself needing to temporarily grant elevated admin privileges in IdentityNow, you may wonder how you can automate the process of granting and revoking these privileges to users. You can manually set user level permissions when a user asks for a temporary elevation, but then you are on the hook for revoking those permissions once they are no longer needed. One way to solve this problem is to install the IdentityNow Management Connector, which is a loopba…

[kavindar_sharma]

Really helpful blog .

[atarodia (Animesh Tarodia)]

You could also use Roles OOTB to achieve this. Here’s the walkthrough:

Temporary Admin Access with Roles in Identity Security Cloud

[Tutorials-Blue] In organizations, there are often scenarios where employees require temporary administrative access to systems or applications for a specific duration. This could be for maintenance activities, system upgrades, or other time-bound tasks. Granting permanent administrative privileges poses a security risk, as it increases the attack surface and the potential for misuse. To address this concern, SailPoint Identity Security Cloud provides a feature that allows for temporary admi…

[colin_mckibben]

I’m going to mark @atarodia 's blog as the solution, as it is the easiest to setup and follows SailPoint standard procedure for access requests. My blog is an interesting thought experiment and can be useful if you need more customization in your request process.