There are 2 call end points given by the Linkedin API
v2/adAccountsV2?q=search
v2/adAccountUsersV2?q=authenticatedUser
that are used to fetch ad Accounts of a user. What is the difference between the two although the purpose of those two seems the same?Are there any benefits of one over the other?
Ad Account Users API allows to manage user access to Ad Accounts, read more here.
Ad Accounts API is mainly for Enterprise or Business Ads Account holders, not personals.
When it stands to fetching Ad Accounts by some criteria then those methods performs different jobs and returns different JSON data structure.
If you want to retrieve the business Ad Accounts by ID, name, reference, type, and status fields then you can use /v2/adAccountsV2?q=search call and append to it all the required parameters. See more details here.
If you require to find Ad Accounts by an authenticated user then you will need to call /v2/adAccountUsersV2?q=authenticatedUser and it will return the Ad Accounts associated with a member whose access token is being passed for the API call.
Related
Has anyone set up an API for a group of users in BeyondTrust, and if so, will the members of the group be able to see and access each others passwords or do I need to create separate API Keys per each user?
I have not tried this as of yet, I do not fully understand the results of attempting an API for a group of users with in BeyondTrust Password Management systems, and I am afraid if I set up an API for a group of users, they will be able to view and utilize passwords that do not belong to them.
Is an API for a group even a thing, or do I have to set up API keys per user?
Password Safe users can use the API to do most of the functions available through the UI. They operate under the same security model regardless of access method, with the caveat that accounts need to be indicated as accessible via the API. This means that you might not be able access every account that you have access to through the UI, via the API but, it does mean you cannot access any account through the API that you don't have access to through the UI.
I have an application registered on Azure AD. The application has been configured to include groups claim on Token Configuration section on Azure Portal. When I access to the application, follow the process to authenticate against AzureAD, and access to an Controller endpoint, I see that the Claims for the user property does not have the groups. Instead, I'm getting a property, hasgroups, defined with true.
I'm assigned to 89 groups, I don't know if there's any limitation about the number of groups and for that reason Azure change the claims (instead one for each group, it's emitting one with the boolean value I have told you).
This situation happens with an organization tenant. I have test the same with my own tenant on Azure and I'm getting the groups. But in my own tenant I'm assigned only to 2 groups. This is the reason I've highlighted the number of groups i belongs to in my organization.
There is a limitation to how many groups can be returned due to size limitations of tokens.
You must always be ready to query for user groups from MS Graph API, e.g. with:
Get group members: https://learn.microsoft.com/en-us/graph/api/group-list-members?view=graph-rest-1.0&tabs=http
Get user groups: https://learn.microsoft.com/en-us/graph/api/user-list-memberof?view=graph-rest-1.0&tabs=http
Check group access for user: https://learn.microsoft.com/en-us/graph/api/user-checkmembergroups?view=graph-rest-1.0&tabs=http
If you get the hasgroups claim, you need to query for groups.
I am using Azure AD B2C and I want a group based user distribution for my application. Lets say I have two subdomains subA.myapp.com and subB.myapp.com. On the other hand, I have two groups subA and subBin Azure B2C. Now a user wants to signin to subA.myapp.com, but is not a member of group subA, I would like to deny the user to sign in.
I know that Azure B2C does not include group info in the access token. So I will actually use Graph API to get the group membership of the user. But I am not quite sure if there is an appropriate event where I could intercept the validation process and manually deny a user to sign-in. Also, I thought I could use one of the *Validator methods of TokenValidationParameters but not sure which one.
I have read Authorize By Group in Azure Active Directory B2C. My problem is different because that problem is trying to protect only some actions based on group memberships, I want to prevent the whole login process to fail based on group membership.
You can use a ValidationTechnicalProfile on a page created by the SelfAssertedAttributeProvider technical profile. Using the validation technical profile, you can first authenticate the user, and then call a Rest API that can look up users group membership and return a successfull/fail response.
If the response is successful, the flow will continue. If it's a failure, an error will be shown to the user.
I'm connected to an API that provides information about cars based on their registration. According to the docs the api can provide both user specific data and general data about the registration supplied.
I am using the connection method which does require specific users data, and therefore does not require me to gain access to any specific users account.
On my end users will visit my application and enter a registration number which I will use to call the API and return all of the information about the car.
Am I right in my thinking that my application is essentially the 'user' as far as the api is concerned, and I will only need to use one access token. I can then use this access token to make multiple API calls (one for each user that searches on my application)?
Or will i need to set up an access token for each user that visits my application and treat them separately.
Only your application making the API requests requires a token, unless the licence agreement/documentation of this car API says otherwise.
As far as your users are concerned, your application is just magically sourcing the registration info from its database.
I have ADFS configured to deliver AD group information for a logged in user returned as claims.
Claim Language:
(sorry for the screen capture... the schemas were interpretted as URLs that I wasn't allowed to post)
Basic claims to return AD groups user belongs to
This returns groups that the user directly belongs to.
Would like ADFS to return effective permissions for the user.
Example:
User MyDomain\Bob belongs to the group Floor3Employees
The Group EntireBuilding contains the groups Floor1Employees, Floor2Employees, Floor3Employees
When getting claims for MyDomain\Bob... would like the groups returned to be:
Floor3Employees
EntireBuilding
The web application receiving the claims from ADFS could probably query AD to figure out the hierarchy of groups, but want to avoid the web application communicating directly with AD.