RyanA.50521 (Customer) asked a question.
I have 2 seperate processes that load details from the apps api and users api into my database. I can see that apps response has a list of users per app - but referenced by href and not the user id. I also see that a self.href is supplied in the user response.
Am I able to join on the href, or do i risk things breaking?
@RyanA.50521 (Customer) - It is not really clear to me what you are asking.
If you are leveraging (listApplicationUsers)
It is going to return an object for each user found including the user's ID: "id": "00ujozz2l7rBsArvF5d7". Additionally, In each of those objects the href provides a link for apps and users. I've included the relevant API documentation for those links:
"app": {
"href": "https://domain.okta.com/api/v1/apps/0oa7xqdfxzfQfetWS5d7"
"user": {
"href": "https://domain.okta.com/api/v1/users/00ujozz2l7rBsArvF5d7"
Calling those would allow the retrieval of additional information as the direct "GET" of a specific resource typically have more information available.
Hey Tim - Thank you for the response. We are very close to alignment. I am attempting to do this in Cribl search, for a specific use case
Basically - I have apps and users responses as you mention, and the data is loaded in Cribl database. I am unable to make additional rest calls, but would like to join the data. Apps response has a list of users, but only the hrefs. I would like to join on href, but it initially doesn't seem possible since the uri doesn't correspond to a unique id (although there are elements that match). Am i wrong here? Any decoding or possibility of making the resource in these url's joinable? I am unable to make more calls to href.
@RyanA.50521 (Customer) I have no familiarity with Cribl and I am not really a DB guy. However, when you list the users belong to the application and get back the 2href links. Those Href links contain unique identifiers.
Each of the hef links within each JSON object within the list contains the href with the unique Identifier for the queried application https://url/0oapplicationID and it will have the associated userID href that is part of the application https://url/00userID. So essentially your "primary key?" on that GET operation would be the href with the applicationID and you should be able to associate all of the hrefs with the corresponding userID's to it.
As far as how to join it. Looking at the screenshot there isn't going to be any relationship between them as they are different resources. This is also something people run into when leveraging Okta Workflows (Or really any API client). For example lets say you GET a list of user's groups. The API is going to return group objects. Those won't be associated with the user objects in the API return because that isn't what was requested. So if you want to process each Group to perform some action you would need to pass the User ID used in the GET query to list their groups along with the foreach so you can perform a group action against that specific user.
In general:
Sorry I can't be much more help. You might want to try over on the devforums instead. This forum is more for troubleshooting specific product problems and less about engineering custom solutions.
@RyanA.50521 (Customer) -- I was thinking about this a bit in the PM yesterday. And there are basically 7 endpoints that all contain different elements of shared / related data:
Users:
Applications:
Groups:
So to basically answer all of your "questions" about which users belong to which application and if they were individually or group assigned and additional specific details about app, user, group resources you basically would need a table for all 7 of them as it should cover the majority of your queries and would have enough associations between them to pull the information needed in a "join" type scenario.
There might be a better way.. but I don't know.
We use cookies to provide the best website experience and to help understand marketing efforts. We may also share data with ad partners to reach potential customers across the web. To learn more, visit our Privacy Policy. Click here for Your Privacy Choices. You may also opt out of this sharing by signaling your preference via GPC, applicable only to the browser signaling the opt-out.
More information
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Select All
We use cookies to provide the best website experience and to help understand marketing efforts. We may also share data with ad partners to reach potential customers across the web. To learn more, visit our Privacy Policy. Click here for Your Privacy Choices. You may also opt out of this sharing by signaling your preference via GPC, applicable only to the browser signaling the opt-out.
More information
These cookies are necessary for the website to function and cannot be switched off in our systems. They are usually only set in response to actions made by you which amount to a request for services, such as setting your privacy preferences, logging in or filling in forms. You can set your browser to block or alert you about these cookies, but some parts of the site will not then work. These cookies do not store any personally identifiable information.
These cookies enable the website to provide enhanced functionality and personalisation. They may be set by us or by third party providers whose services we have added to our pages. If you do not allow these cookies then some or all of these services may not function properly.
These cookies allow us to count visits and traffic sources so we can measure and improve the performance of our site. They help us to know which pages are the most and least popular and see how visitors move around the site. All information these cookies collect is aggregated and therefore anonymous. If you do not allow these cookies we will not know when you have visited our site, and will not be able to monitor its performance.
These cookies may be set through our site by our advertising partners. They may be used by those companies to build a profile of your interests and show you relevant adverts on other sites. They do not store directly personal information, but are based on uniquely identifying your browser and internet device. If you do not allow these cookies, you will experience less targeted advertising.
Select All
@RyanA.50521 (Customer) -- I was thinking about this a bit in the PM yesterday. And there are basically 7 endpoints that all contain different elements of shared / related data:
Users:
Applications:
Groups:
So to basically answer all of your "questions" about which users belong to which application and if they were individually or group assigned and additional specific details about app, user, group resources you basically would need a table for all 7 of them as it should cover the majority of your queries and would have enough associations between them to pull the information needed in a "join" type scenario.
There might be a better way.. but I don't know.