View "claimStatus" and Email in Atlassian Cloud

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

Hello Sailers, I am currently trying to connect Atlassian Cloud to our ISC using the OOTB connector Integrating SailPoint with Atlassian Suite Cloud

I have some externally managed users (invited) users in our Atlassian Suite, and I am not seeing their E-Mail Address inside ISC on the account page. It is empty, and this is based on the privacy settings of the externally managed user. If their configuration is set that anyone can see the contact e-mail, then it is seen in ISC but the default is only yourself and admins can see it.

Using the API manually, and the Org-API-Key, it is possible to read it at the following API Endpoint:

GET https://api.atlassian.com/admin/v2/orgs/{orgId}/directories/{directoryId}/users
Authorization: Bearer <org-api-key>
Accept: application/json

This needs an API key of the organization, the service account which performs user aggregation is a Site-Admin.

Has anyone been able to combine the different keys/ API endpoints, so that the emailAddress field gets populated for externally managed users? Or if not, how do you handle it? Is there a way to see that the user is invited/ externally managed?

Empty Field:

image
image1675×799 41.4 KB

Using Postman to view using the API Endpoint mentioned above:

image
image841×420 28.6 KB

Thanks in advance for any tips!

2

I would look at the api response vs the schema and make sure they match. Based on your screen prints it looks like email mapping is mismatched. I would update in the schema emailAddress to email.

3

For org-managed accounts (internal employees), the emailAddress populates so in my opinion the schema is correct, but for invited accounts there is no emailAddress

4

I currently have the same issue and discovered that the out of the box connector does not use the Organizations REST API (base url https://api.atlassian.com/admin/v2/).

The API it uses has base url https://{{URL}}.atlassian.net/rest/api/2/, but that one does not expose the e-mail address, which is kind of a vital attribute.

I’m currently considering setting up a web services connector to get the information, but I’d rather not, because then I’d also have to configure all of the other operations.

Is anyone else having this issue??

Kr,
Pieter.

5

Same exact issue in my org as well. I couldn’t find a workaround, so I ended up building a web services connector and doing all the work myself.

Following this thread in hopes of a OOTB solution! Or maybe I can give my web services version to SailPoint and they can make it OOTB :rofl:

6

That’s a pity! Did you end up reporting this or creating an item on the ideas portal?

Kr,
Pieter.

7

There was already one out there, so I didn’t feel the need: https://ideas.sailpoint.com/ideas/GOV-I-5063

My version ended up needing customization that required a connector rule anyways, so it was all for the best.

If anyone needs help configuring this using a web services, happy to help!

8

Thanks, I gave it my vote :)!

9

@othornewill,

If you’re using a SaaS Connector, one possible workaround is to use a Customizer (or, a Connector After Rule for VA based connector) to make an additional API call and populate the email attribute.

For example, in one of our use cases, we use a customizer Connectivity Customizers | SailPoint Developer Community to set an attribute after account aggregation

.afterStdAccountList(async (context: Context, output: StdAccountListOutput) => {

       logger.info(`Running after account list for account ${output.identity}`)

       output.attributes.acces="acces_xxx_sailpoint"

        return output

    })

    .afterStdAccountRead(async (context: Context, output: StdAccountReadOutput) => {

            output.attributes.acces="acces_xxx_sailpoint"

            return output

        })

In your case, you could:

  1. Check whether the account is an externally managed user.

  2. Make an additional API call using the Organization API key to retrieve the user’s email address (optionally filtering the request if the API supports it).

  3. Set the value in the output object, for example:

    output.attributes.email = externalEmail;

  4. Return the updated output.

The email attribute should then be populated in ISC after aggregation.

Thanks.

10

Would it be possible for you to share the full rule which aggregates the data from the other endpoint? Right now I think that the OOTB connector makes a request to

GET https://$tenant.atlassian.net/rest/api/3/users

for Org-Managed accounts, it gives the following format:

{
    "self": "https://$tennat.atlassian.net/rest/api/3/user?accountId=ID:GUID",
    "accountId": "ID:GUID",
    "accountType": "atlassian",
    "emailAddress": "Email.Address@example.com",
    "avatarUrls": {
        "48x48": "https://redacted.com",
        "24x24": "https://redacted.com",
        "16x16": "https://redacted.com",
        "32x32": "https://redacted.com"
    },
    "displayName": "Display.Name.OrgManaged",
    "active": true
}

and for externally managed users, it returns this (notice the missing emailAddress value)

{
    "self": "https://$tennat.atlassian.net/rest/api/3/user?accountId=ID:GUID",
    "accountId": "ID:GUID",
    "accountType": "atlassian",
    "avatarUrls": {
        "48x48": "https://redacted.com",
        "24x24": "https://redacted.com",
        "16x16": "https://redacted.com",
        "32x32": "https://redacted.com"
    },
    "displayName": "Display.Name.ExternallyManaged",
    "active": true
}

Does it need to be an after aggregate rule for the VA to make the additional API calls? What is the best way to manage secrets in that? because it needs to make a call to a different endpoint with different authentication.

GET https://$tenant.atlassian.net/rest/api/3/users

vs

GET https://api.atlassian.com/admin/v2/orgs/{org-id}/directories/{directory-id}/users

Thanks in advance for any tips! :slight_smile: