There is no documentation around how the Application Role Assignments list that is generated from this AAD Graph API call is determined:
https://graph.windows.net/contoso.com/users/simon#contoso.com/appRoleAssignments
For instance, if the user has Office 365, no assigned Office 365 Apps appear in the Graph API response, yet if this user browses to https://myapps.microsoft.com/contoso.com they see them listed.
Can someone clarify the logic used to build the Apps returned in this list and if it is possible to retrieve all the applications assigned to the user?
The user's appRoleAssignments navigation property should contain all of the roles that the user has been assigned on apps. In case an app does not declare any appRoles that can be assigned to users, there will still be one entity here with an all-zeros GUID.
For example, I've assigned one of my test users to an app that has no roles, and Get-AzureADUserAppRoleAssignment -ObjectId user-object-id returns:
DeletionTimestamp :
ObjectId : 1YoOkUy2bESZDaQwZRhU0S-UYlhvd3FJsJikOAWHrsI
ObjectType : AppRoleAssignment
CreationTimestamp : 17.1.2016 15.40.03
Id : 00000000-0000-0000-0000-000000000000
PrincipalDisplayName : Test User
PrincipalId : 910e8ad5-b64c-446c-990d-a430651854d1
PrincipalType : User
ResourceDisplayName : TodoService
ResourceId : 6b5b5ad6-54ce-415f-ad04-0a276ce086b0
And also one for an app that does specify roles:
DeletionTimestamp :
ObjectId : 1YoOkUy2bESZDaQwZRhU0YAvk4B2fQdPqcTGnjNiP_0
ObjectType : AppRoleAssignment
CreationTimestamp :
Id : 06608f41-55fb-400a-8da2-3d51909a0449
PrincipalDisplayName : Test User
PrincipalId : 910e8ad5-b64c-446c-990d-a430651854d1
PrincipalType : User
ResourceDisplayName : TestApp
ResourceId : ecf84db8-3333-43d0-809a-aaef620a14bf
Note the Id property specifies the id of the role that the user has on that app. In the case of the first one, they just have general access.
As for why Office 365 apps don't show up there, if I recall correctly you do not assign them the same way through the Azure AD user management? The app assignments may be an internal thing in O365 and Azure AD does not know about it. License assignments can be found from the licenseDetails navigation property of the user (or Get-AzureADUserLicenseDetail with Azure AD v2 PowerShell).
Related
I have a Microsoft Teams tab app and I'm using SSO for authentication. My users are both native and guests. My requirement is to show different screens depending on the type of incoming user (native/guest), so I have to identify the user type first. To ensure security, I first obtain the id token for the incoming user and then validate it first before identifying the user type. Is there any reliable way to identify the incoming user type with just the id token? I don't trust the info in tab context.
If you don't want to use Microsoft Graph API, you could add all the guest user into a security Group and include Groups claim in your token as instructed here. You just need to modify the "groupMembershipClaims" field in application manifest:
"groupMembershipClaims": "SecurityGroup"
Then the ID token will contain the Ids of the groups that the use belongs to like below :
{
"groups": ["1ce9c55a-9826-4e32-871c-a8488144bb32"]
}
You can also Add app roles in your application and receive them in the token.
You can use microsoft graph api(beta) get user.
https://graph.microsoft.com/v1.0/users/{id | userPrincipalName}
If the id token contains objectId of the user, just put the objectId as the parameter of this api. In the response, we can find an attribute userType. The value of this attribute could be Member or Guest.
If the id token doesn't contain objectId of the user, just contains email. We can also put it as the parameter in the graph api, but if the email is a guest user, the api will not get response data. So I asked you if it contains objectId in the comments.
By the way, the attribute userType just exists in the beta version of microsoft graph api but not exist in the v1.0 version microsoft graph api. So if you're not comfortable with beta version, I suggest to use Azure AD graph api(get user) instead of Microsoft graph api.
Hope it helps~
Within Azure AD B2B I have created an application registration (the resource) with an appRole for "User" and "Application".
If I assign the servicePrincipal (the client) to this appRole -> the accessToken contains the appRole.
servicePrincipal(client) <-> appRoleAssignment <-> servicePrincipal(resource)
this works as expected
If I assign the serviceprincipal (the client) to a top level security group and assign the security group to the appRole -> the accessToken does NOT contain the appRole.
servicePrincipal(client) <-> security group <-> appRoleAssignment <-> servicePrincipal(resource)
this indirection works for users, am I missing something why this would not work for servicePrincipals?
All of your steps are right.If you want to assign an app role to an service principle , you should assign one by one, it not works if you add a service principle into a group that assigned with an app role. As #juunas said , maybe this is something like a bug .
I don't think you have missed anything. It does indeed work for users.
It's either a bug or a feature :) Could be that application permissions are not wanted to be assigned via groups.
(which is what appRoles of type Application are)
We have leveraged B2B to add 8 domains into one domain. Upon completion of adding other domain users as guest users, they are able to access the SharePoint site successfully. But the user logged in information like login name, Email address & user ID information is empty in SP page context info.
I have tried with a scenario like adding my organization account to the client tenant and verified. I'm able to get the context info about login name, email address & User ID.
Let me know if any one faced similar issue & any configurations to be made at source Azure AD/New Azure AD?
I am building a web app with go and GAE. I would like to use Google Accounts for authentication. The appengine/user package contains a type, User. I was planning on using ID property of User as the ancestor to descendent entities in the Datastore. However I'm confused by the comments in this section of documentation:
type User struct {
Email string
AuthDomain string
Admin bool
// ID is the unique permanent ID of the user.
// It is populated if the Email is associated
// with a Google account, or empty otherwise.
ID string
FederatedIdentity string
FederatedProvider string
}
Source: https://cloud.google.com/appengine/docs/go/users/reference#User
Under what circumstances might an email not be associated with a google account and therefore ID be empty?
I'm very new to go and GAE so please excuse my ignorance.
There are several key differences between email and id. E.g. "The app can also access a user ID that identifies the user uniquely, even if the user changes the email address for her account." Also "Every user has the same user ID for all App Engine applications."
Like ThunderCat said, if you use a Federated Login (OpenID was the only one supported, but is no longer), then you will not get a user id.
See the docs for more info.
Just wondering if the userId returned by calling the user.getUserId() should be treated as a secret, or can it be used in public URLs? for example, the profile page URLs look something like http://example.com/userprofile/11901930903930 where 11901930903930 is the Google generated userId on Appengine.
This is the function we are using to get the userId:
UserService userService = UserServiceFactory.getUserService();
User user = userService.getCurrentUser();
String id = user.getUserId();
Actually, I found this info on Google and the conclusion is that they should not be used publicly.
From Google:
Accessing Account Information
While a user is signed in to an app, the app can access the account's email address or OpenID identifier for every request the user makes to the app. The app can also access a user ID that identifies the user uniquely, even if the user changes the email address for her account.
The app can also determine whether the current user is an administrator (a "developer") for the app. You can use this feature to build administrative features for the app, even if you don't authenticate other users. The Go, Java, and Python APIs make it easy to configure URLs as "administrator only."
Note: Every user has the same user ID for all App Engine applications. If your app uses the user ID in public data, such as by including it in a URL parameter, you should use a hash algorithm with a "salt" value added to obscure the ID. Exposing raw IDs could allow someone to associate a user's activity in one app with that in another, or get the user's email address by coercing the user to sign in to another app.
Link to page