I'm trying to implement security to a backoffice CLI tool (NodeJS) that calls a REST api (Java/JAX-RS) for performing database operations etc.
As we're using Azure AD for all our user accounts I'd like to use it for authenticating our users and also for authorization.
The authorization is needed since not all members of the AD is supposed to use the CLI, and there are two types of users of the CLI with a different set of available commands, meaning that even if you are able to use it, some features might be locked out depending if you are an operator or administrator.
I've managed to create two applications in Azure AD, one for the CLI and one for the API. I can login using our AD credentials, fetch Access tokens for the CLI app id requesting the REST API resouce. On the client side I'm using https://www.npmjs.com/package/simple-oauth2 .
On the Java side the tokens are validated against Microsoft public keys, so everything seems to work out fine.
But, how should I lock down the users to either operator or admin roles? One naive way I can think of is to have the user/role correlation in the REST API and only use the OAuth flow for authenticating the user. But I guess that's what the AD is there for... Could OAuth scopes help me in this case?
Or should the REST API call the AD to query for users group memberships, once it receives the access tokens and knows the end user identity?
Thanks in advance!
Use the Application Roles.
Here you will find good description what application roles are and how to handle them:
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
The recommended resources at the end and also very helpful and will guide you through the process.
Also, when developing CLI it is recommended to use the Device Flow - described here with sample code (.net core) here.
Related
I built a SaaS application that needs to retrieve all our customer's Users & Groups from Microsoft Graph daily.
The setup part can be interactive but the Microsoft Graph is not (as it is a background task on the server-side).
I have a hard time understanding which flow I should use. When I look at the list of Authentication flows (https://learn.microsoft.com/en-us/azure/active-directory/develop/msal-authentication-flows), I see naturally the Client credentials flow recommended for daemons apps. However, the drawback seems the setup complexity. The administrator needs to manually register an app, generate the secret, etc. which I would like to avoid.
On the other hand, I see the other flows (Authorization code, etc.) where there is a very streamlined authentication process. It seems that I can store on the backend side the refresh token and use it from the backend in a daemonize way. It seems to be the best of both worlds. Is this pattern correct? Is it reliable?
Note: My SaaS has a UI and users can log in to it during the setup part.
The administrators won't need to install your app manually and generate the secret. It's you who generates the secret for your server side and you will use your client ID and the secret to access Graph in offline mode. For that you'll need your clients' administrators' consent which you can get by redirecting them to admin consent page which will present the list of permissions required by your application to access the Graph data.
All of this is described here: https://learn.microsoft.com/en-us/azure/active-directory/develop/v2-oauth2-client-creds-grant-flow
I have an old windows application written in VB.NET with SQL server backend. Currently the new user additions, deletion, adding entitlements etc. are managed by an old approval workflow system. After getting approvals, the user details and entitlements are inserted in to the SQL server database table manually.
I am trying to integrate this application with the SailPoint's Identity and access management. So the new user addition, deletion update and adding entitlements etc will be done through Sailpoint. For this, I would require to create a WEB API which can be called by Sailpoint and expose the functionalities(add user/delete user/add entitlements). The only consumer to this API is SailPoint.
I am new to OAuth and below are the grant types that I came across. But not sure which one I should be using in this particular scenario.
1.Implicit Grant
2.Resource Owner Password Credentials Grant
3.Client Credentials Grant
4.Authorization Code Grant
I have done research on the different authentication methods that we can use to secure the web api. But still confused on which one to apply in this scenario as this new web api is going to be made available in internet.
I already tried developing a POC with the OAuth 2.0 with password grant type referring this article. But when I read articles in the internet I found that the password grant type is not that secure and is deprecated.
Could you please advise on which grant type(client credentials/authorization code/implicit) to use in this scenario. I believe authorization code is used when the user is directly trying to access the API. In this scenario, SailPoint will be calling the API in the backend programmatically when they insert a new user in their UI.
I think it's a good approach to use client credentials in this case because the communication between IIQ and your Web API can be considered an API-to-API communication, I mean, IIQ is acting on behalf of itself in this communication.
See this article for more details - https://dzone.com/articles/four-most-used-rest-api-authentication-methods (bold part by myself)
OAuth 2.0 provides several popular flows suitable for different types
of API clients:
Authorization code — The most common flow, it is mostly used for
server-side and mobile web applications. This flow is similar to how
users sign up into a web application using their Facebook or Google
account.
Implicit — This flow requires the client to retrieve an
access token directly. It is useful in cases when the user’s
credentials cannot be stored in the client code because they can be
easily accessed by the third party. It is suitable for web, desktop,
and mobile applications that do not include any server component.
Resource owner password — Requires logging in with a username and
password. In that case, the credentials will be a part of the request.
This flow is suitable only for trusted clients (for example, official
applications released by the API provider).
Client Credentials —
Intended for the server-to-server authentication, this flow describes
an approach when the client application acts on its own behalf rather
than on behalf of any individual user. In most scenarios, this flow
provides the means to allow users to specify their credentials in the
client application, so it can access the resources under the client’s
control.
I am currently working on a project that provides a services to enterprises companies. I want companies to be able to set up an account, and link their SSO to it allowing their employees to login. Each company account must have private data, so that other employees from other companies can't access their data. I must therefore be able to identify what account/company the user is from when they log in.
I have been looking into how to set something like this up, I know I should be using OAuth and SSO. But i have been struggling to find any documentation now how SSO integrates with OAuth. Can some one point me to a good guide/documentation on this?
At a high level this is federation, which should work like as follows - and nothing should need to change in your UIs and APIs:
Your UIs and APIs use tokens from your own Authorization Server
Your Authorization Server redirects to Company SSO Systems (Identity Providers)
These Identity Providers can use protocols such and Open Id Connect and SAML
My visual blog post may help you to understand the overall process. Account linking is the tricky bit, where you need to identify the user - most commonly by email - then perhaps match that to data in your own system.
I'm trying to create a web api in Azure that allows a user to access it.
I don't care whether the user calls the api via postman, curl or a .net console app, as long as the user can authenticate against the AzureAD protecting the resource, he should be in.
However, all documentation I have seen so far require me to register a client with AzureAD.
So, I've got an example working, but I had to register the console app in AzureAD.
Now, there maybe hundreds or thousands of developers developing apps against my API. Obviously I don't want to have to register each single one with AzureAD. In fact, I don't even want to have to know about them.
How can I actually do that? I care about users, not client apps.
Or is this something AzureAD B2C does?
Now, there maybe hundreds or thousands of developers developing apps against my API. Obviously I don't want to have to register each single one with AzureAD. In fact, I don't even want to have to know about them.
You only need to register one app(web app) to protect the web API. And if you want the web api consumed by different organization, you need to enable the Multi-tenanted feature on the Azure portal.
After that, if the other developers want to consumer the web API, they also need to register the one app on their tenant and grant you web API app to their app. After that then can acquire the access token for the web API and request the web API with the access token.
More detail about the scenario about calling web API, you can refer the code sample below:
active-directory-dotnet-webapp-webapi-openidconnect
And if the sencario is multi-tenant, you also can refer the document below about detailed info:
How to sign in any Azure Active Directory (AD) user using the multi-tenant application pattern
Context
I'm building a web application deployed to Azure Webapps where users need to sign in. To accomplish this, I'm leveraging Azure AD with OAuth 2.0 Authorization Code Grant. Since I'm using Nancy (with the ASP.NET host) instead of MVC, I can't follow the official Azure AD MVC examples where all the OAuth handling seems to happen magically in the background.
Redirecting to the OAuth endpoint is straight-forward, and the user is also correctly redirected back to my application with an authorization code.
Problem
Now I need retrieve the user ID in order to match it to the user database in my application. I'm using ADAL for this, because this is basically step D & E of the authorization code grant flow, from what I understand.
Now what puzzles me is that this use case is not supported by Azure AD, stating that
The client '[ClientId]' and resource '[ResouceId]' identify the same application.
Also, as indicated by this answer, "ADAL is not meant to achieve web sign-on in a web application."
I've been able to work around this problem by creating two applications in Azure AD, as suggested by this blog, but it feels like I misunderstood something. This could very well be the case, as I am new to OAuth and Azure AD.
So my question is, what is the correct way to authenticate a user from a non-MVC web application using Azure AD?
the OWIN middleware should work with non-ASP.NET as well. See for example http://unlustrously55.rssing.com/browser.php?indx=24287735&item=13 - in your case you will have to use the OpenId Connect one or the ww-federation one.
Is this purely for users inside your organisation/tenant? It sounds like it.
Why don't you use an App Registration in Azure AD and grant it permissions to access the users profile? You should then be able to retrieve a user's UPN from the token. Please see here:
https://learn.microsoft.com/en-us/azure/app-service/scenario-secure-app-authentication-app-service