Service or daemon authentication to the Microsoft Graph grants access to a limited number of functions.
For example, to be able to work with Planner and tasks, you have to be logged in as a user. In other case, we can't access most of user details, we can't access user's files and so on.
Why service or daemon must have more permissions then now? In our case, service should automatically create Planner tasks and Calendar events for specific users or groups according to automatically registered events. Sometimes it should also create or add or read files in OneDrive of this user. Also automatically, of course. Due to Microsoft Graph restrictions, it is easier to use additional 3rd-party service to track tasks, or even write our own. The same situation with files.
Microsoft Graph looks like a powerful API, but due to its access restrictions it becames unusable when you need to made something automatically, without any user actions.
What is the reason for most of these restrictions?
Is there any walkarounds?
Office 365 works perfect with deamon applications but not in your usecase. It works great for modifying a user' calendar for instance. See here https://learn.microsoft.com/en-us/graph/api/user-post-events?view=graph-rest-1.0&tabs=cs
Apart from that, if you want to have something changed in the graph api. The best way to let Microsoft know is to create an item on UserVoice. This is to let users influence what features they need, maybe you can express your wishes there. https://microsoftgraph.uservoice.com/forums/920506-microsoft-graph-feature-requests
Related
I'm mid-way through a task to migrate a legacy .NET MVC app to use Single Sign On (SSO) to make integration with a to-be-developed mobile app possible. I'm planning on using Azure AD B2C to facilitate this and based on my researched, I need to use custom policies to achieve the required functionality.
Work on this migration is proceeding very slowly. I'm finding the custom policy XML very clunky to work with. It's going to take quite some time to achieve parity with the existing system given the current velocity. I'm wondering whether it would be wise to sidestep a lot of the migration headaches by using the Microsoft Graph API in place of custom policies.
Take registration for example. It appears common to redirect the user to a SignUp.xml custom policy (or the integrated SignUpOrSignIn.xml) to handle adding the user record in the AD B2C data store. Part of this policy would involve calling a REST API to create a corresponding record for this user in the app's database (stores email settings and such). Instead of using these custom policies, my plan would be to instead take the existing registration process and simply add a step which creates the user record on the B2C side using the Microsoft Graph API.
It appears like most things I need may be achieved using the Microsoft Graph API. Things I'd need that I can see are not available are:
logging in to a user account and;
sending verification emails
Are there any other common authentication-related tasks I'm likely to need that couldn't be achieved using the Graph API?
As far as downsides, the fact I'd be handling user passwords (even if it was just to create the user and nothing else) is an obvious concern, but perhaps acceptable. The main thing I'm after is a simple SSO solution that generates secure access tokens (incl. handling reset tokens, etc). I hope then, that this could be a feasible option.
You will miss out on password reset, profile edit, SSO and token expiration etc.
A better way may be to use the base custom policies and achieve a lot of what you need by having the policy call REST API's.
What is your use case?
I have a microservice architecture, where one Single Page Application accesses three different APIs:
I am securing those APIs via the Microsoft Identity Platform and therefore I also need service principals.
My first approach matches with all the examples I found on blogs or in the MS docs.
In this case I have one app registration for the client app and three additional ones for the APIs:
This has the following impact:
Each API has its own audience.
I get four service principals for each application.
I get three different places where I have to administrate the user assignments to roles. (for example: User A can read assets from API A etc...)
This works, but comes also with some problems:
The other admins that are managing which user is allowed to do what are confused about three different places they have to assign roles. It would be nicer to have one central place.
The roles of the users are not placed in the ID tokens, because only roles of the client application would go there... but I do not want to assign permissions in the client app again.
If API A wants to call API B or C, I need two access tokens for other APIs.
This lead me to a second idea:
Here I have one registration for all 3 APIs. This already solves problem 1 and problem 2. But it also gives me a strange feeling, because I never found other people doing so.
Also my ID tokens are not telling me the roles, so to fix this, I could even go another step further to a single app registration for everything:
Now one registration exposes an API and consumes this API also. Something what is possible and seems to solve my problems. I even get all roles for the users in my ID tokens AND in my access tokens now.
However, this is contradictive to all other examples I found.
Which disadvantages does the last solution have?
Which of the three approaches should I chose?
Which disadvantages does the last solution have?
One thing that comes to my mind is that you want API A to be able to edit data in e.g. MS Graph API, so you give it the app permission to Read/Write Directory data.
Now with the shared app registration this permission has also been given to API B and API C.
So the principle of least privilege may be violated in the second and third options.
But it does make it easier to manage those APIs as you noticed.
The third option does open up the door for the user to acquire access tokens to any APIs that you might want to call on behalf of the current user from your APIs.
So if you wanted to API A to edit a user through MS Graph API on behalf of the user, you'd have to require the read/write users delegated permission (scope) for your app.
This would allow the user to acquire this token from your front-end as well, even though that is not intended.
Now they would not be able to do anything they wouldn't otherwise be able to do since the token's permissions are limited based on the user's permissions, so this might not be a significant disadvantage.
Which of the three approaches should I chose?
As with many things, it depends :)
If you want absolute least privilege for your services, option 1.
If you want easier management, I'd go with option 3 instead of 2.
There was that one thing I mentioned above about option 3 but that does not allow privilege escalation.
I am working on a service that logs into JIRA and performs few operations that are not associated with a particular user. Right now, I'm using a virtual account and authenticating the JIRA by the accounts username and password. The use case requires a significant number of such services to be created. The current solution will be messy to maintain, because I need to keep a track of service level logs, which will require creation of a large number of virtual accounts, whose management is difficult. Is there a service account like concept in JIRA that allows a service to perform authentication as an application like on Google cloud?
Their reference about the REST API.
I played with it once, remember it requires API key or token maybe.
While the Microsoft Graph API seems to be very complete feature wise, it seems like I am stuck at a fairly easy request. For a small web application I want to list apps that are registered in Azure. What a want to do with them is a little bit out of scope, but in the end I want to show the user some important applications (which we flag in some way - using tags or something like that) that the user has access to.
Now, using the /applications resource in the beta endpoint of the Graph API I can retrieve a list of applications. Now, the application does not need admin consent. When requesting the apps, it retrieves all registered apps, which is a bit odd I think. Why would it return all apps and not just the ones that are assigned to me?
But okay, lets move on. Now I have the list of apps (or the metadata of it). How can I determine if the signed-in user has access to this application (or it doesn't require assignment). Am I missing something or is this nowhere to be found?
You can use query parameters to customize responses. Please check the link https://learn.microsoft.com/en-in/graph/query-parameters
I have used appRoleAssignment with the neccessary parameters to retrieve all apps a user has access to. Turned out to be quite simple. Beta only, but stable.
https://graph.microsoft.io/en-us/ seems to be built on top of the Azure AD graph - https://graph.windows.net/
I haven't found a lot of how graph.microsoft.io was built, but it seems like it is a superset of the original Azure AD API, together with the stuff to access data from Office 365 through the graph.
What stands out to me is that either they would have passed through queries from graph.microsoft.io to graph.windows.net or they would have rebuilt it all from scratch. So, I'm trying to understand how to build my own such graph. I will use Azure AD, which will enable my authentication and authorization. It will give me a graph of the users in my organization. But for custom applications that also use Azure AD for login, I would like them to be available via the graph, like how the Office 365 apps are available via the graph.microsoft.io site.
So far, to implement something similar, it seems like I can use the core Azure AD graph for a specific set of user data, and for apps that use the Azure AD instance that I provide, I can require them to implement an Odata endpoint which describes how their own data can be accessed.
Is this a good approach?
It's certainly pretty much exactly what we do, so who am I to argue. However, rather than going to Azure AD directly for the graph of users in your org, I'd encourage you to go to MS Graph for that data, as we'll be looking to add richness and functionality there rather than in the underlying AAD Graph as time marches on, and also it will enable you to link across easily to other Office apps of course.
Over time, we'd like you not to have to do this, but rather to bring your own apps' data into the Microsoft Graph in some fashion, but we are a ways away from having that facility available.