I have a WebAPI (A) hosted on Azure protected by Azure B2C (B) which is being called by a mobile app (C) - this is all working correctly.
I now want to allow third parties to access my API via API Management on the same platform but I am getting extremely confused with authentication and "audiences".
The API Management developer portal has been configured as per the Azure documentation so that when the developer makes test calls on the portal it prompts for authentication using the B2C domain (B). To do this it uses an application registered against the B2C domain.
However when I want to implement the API from a third party system (D) I need to allow the system to impersonate a user when calling my API (A) so that operations happen in the context of an authenticated user on the domain (B).
I know B2C does not yet support "On Behalf Of" as a valid flow so I use hellojs to obtain an access token on the client which I pass to the third party system API via a custom head which it then appends as an Authorization header to it's call to the API.
The API Management product expects a "subscription key" to identify the products the third party implementation can use.
Does this mean with regards to the authentication part that every third party system using my API would use the same oAuth "audience" id and therefore the same Active Directory app?
It makes more sense to me that each third party implementation would have a different app on Azure Ad but that would mean my Web API would need to recognise a huge number of audience ids and redirect uris?
Finally, how do i "hide" the Web API endpoints from public use - surely use of the audience id would allow people to circumvent the API Management product?
Apologies if I have mixed any terminology up.
1) Does this mean with regards to the authentication part that every
third party system using my API would use the same oAuth "audience" id
and therefore the same Active Directory app?
They will use the same resource/scope id (i.e. audience) e.g. https://yourwebapiAppIDURI/Read but they would all have their own application IDs.
2) It makes more sense to me that each third party implementation
would have a different app on Azure Ad but that would mean my Web API
would need to recognise a huge number of audience ids and redirect
uris?
Yes they should register their applications as clients to your B2C Auth server.
The 3rd party apps should be setup in the AAD portal to have delegated access to your web API (. "Access yourwebAPIname"). If your web API exposes any scopes access to those can be delegated too.
Now when they start the token request by redirecting the user to your Auth Server, they should provide their client id and a resource/scope value of your web APIs App ID URL e.g. https://yourwebapiAppIDURI/Read.
That should result in a token with:
aud value of the Application ID associated with https://yourwebapiAppIDURI/
scp value of Read
OK, so B2C doesnt use consent:
Azure AD B2C does not ask your client application users for their consent. Instead, all consent is provided by the admin, based on the permissions configured between the applications described above. If a permission grant for an application is revoked, all users who were previously able to acquire that permission will no longer be able to do so.
Related
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 have created a Single Page Application with Angular and authentication/authorisation is managed by Azure AD. I have used MSAL.js to initiate the implicit flow.
Everything is working fine, but now my client wants to use her own identity provider (IDP) so that users have a single point of entry for all apps (including mine). This IDP is not mainstream, it is built in-house by the client;
I want to keep using Azure AD to manage authorisations (groups, roles...). I also want my application and its dedicated backend API to be registered in Azure AD, not in the third-party IDP.
Azure AD should remain responsible for providing the Access Token to the SPA in order to call the API.
Somehow, I should redirect the user to the third-party IDP login form and upon successful login it will redirect to my SPA, which should then associate the tokenID with an AzureAD account and retrieve the Access Token (I suppose I will have to create an account in Azure AD for users identified in the third-party provider)
However I'm having a hard time figuring out how to achieve this and if it is at all possible ?
What would be the recommended approach for this scenario ? Can I still use MSAL.js or do I have to rely on something else ?
ARCHITECTURE
Your goals are completely correct and you should not need to change a single line of code to integrate a new IDP - so you can continue to use MSAL.js.
PREREQUISITES
In order to integrate their own IDP into your system you need to insist on certain prerequisites:
The client needs to provide a Standards Compliant Identity Provider
Typically the IDP needs to communicate with your Authorization Server (Azure AD) via either Open Id Connect messages or SAML2P messages
A home grown IDP may not meet these prerequisites in which case you need to explain to the client that they need to get standards compliant.
HOW FEDERATION WORKS
Your UI will redirect to your AS
The AS will redirect to the IDP, when given a trigger
The user will authenticate in the IDP
The IDP will post a token to your AS to identify the user
The AS will issue another token to your UI
Note that there is no coding involved here - there is only standards based integration between vendor systems.
WHAT THE CLIENT WILL GIVE YOU
Client details are often supplied by giving you their metadata document, and these details are then configured in Azure AD as a trust entry:
The entity id of the IDP
The token signing public key for IDP tokens, so that your AS can validate them
A URL to redirect to
WHAT YOU WILL GIVE THE CLIENT
A similar trust entry will need to be configured in the client IDP so that it trusts requests and issues tokens - though no certificate is usually needed here:
The entity id of the AS
A URL to post tokens to
TRIGGERING THE REDIRECT FROM THE AS TO THE IDP
One option is to forward the entity id to the authorization server in Open Id Connect redirects. Often an 'idp' query parameter is used, something like this:
Client accesses your app with a bookmarked URL:
https://app.mycompany.com?idp=urn:client.com
You add an extra parameter to the Open Id connect redirect to tell it where authentication should happen:
https://login.mycompany.com/authorize?client_id=XX&idp=urn:client.com
AZURE AD SPECIFICS
Once you understand the high level process there is some technical stuff to configure the connection and you'll need to consult vendor documentation, such as this Microsoft Azure B2B article.
PRACTICE
If you haven't done this before then you need to invest some time to get a connection working and then document the process.
You can use Windows Server and ADFS to simulate a client connection, then integrate it as a SAML2P connection. There is a learning curve though, and you'll need infrastructure such as ADFS certificates.
CompanyA is integrating with CompanyB where CompanyA's users will be buying devices of CompanyB.
CompanyA wants to show user's device(CompanyB) details on their app by calling
CompanyB's API on each user login.
CompanyA user is authenticated on CompanyA IAM.
CompanyA has to call register device when user tries to add an device first time.
Help me to identify the flow which i can use to query particular loggedin user's device only.
Do i need to create duplicate user account on CompanyB's IAM?
If i use client credential flow for API to API call, access token given by CompanyB is only provides access for API calls but it does not tell that on behalf of correct user only call is invoked.
Assume that CompanyA uses IdentityServer or any other provider as IAM and CompanyB uses Azure AD B2C.
Any other approach?
Please see below diagram,
You should be able to do this by making the Company B API multi-tenant in their Azure AD.
There are other options surely, this is just the first one that came to my mind.
Overview of the multi-tenant pattern
You would have to do admin consent on it to get the API's service principal in your Azure AD tenant.
The Company B API can give you an endpoint for doing this, redirecting you with the proper parameters to the authorization endpoint. How to send a sign-in request
After doing this, you should be able to then require permissions on the API from Company A API in your tenant (configured in Azure AD).
Configure a client application to access web APIs
After doing those things, your API should be able to use On-Behalf-Of grant flow to get an access token for Company B API.
Using Azure AD On-Behalf-Of flow in an ASP.NET Core 2.0 API
Company B API must be configured to accept access tokens from another issuer than their Azure AD of course.
In general multi-tenant scenarios, the issuer validation is commonly turned off.
If Company B wishes to have control over this, currently they will have to explicitly list the valid issuers.
Issuer values look like this: https://sts.windows.net/31537af4-6d77-4bb9-a681-d2394888ea26/, the GUID is your Azure AD tenant id.
The Company B API can extract the tenant id and user object id from the access token, and authorize the user to resources based on them.
I was looking at the AWS side and looks like they have something that could meet the requirements
https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_common-scenarios_federated-users.html
Was wondering if something like this exists in Azure.
Background
I have a MVC 5 Web App and hosted in Azure App Service as Web App and secured with Azure AD; Anybody with valid AD credentials can authenticate themselves and view all HTML Content in the Web App;
Objective
I need to give just one of these MVC-View to outside individuals to view. For such we have already created an User in Azure AD which we will be sharing the details with the outside world. Hence, the thrid party will need to write some code to authenticate to our Azure AD and view this HTML content non interactively (Which means without allowing the third party app to prompt to enter user credentials from Azure AD).
What I have thought about
Assume that I am the third Party, I am going to authenticate to Azure AD from a Console/WinForms/HTML
Page and get myself a token; Then I will be using the token, to open
up a Browser to view this page.
Challenges I see
Session Expiration
Session Validity
Putting everything intto a Picture
Please show me some guidence to accomplish the objective.
Hence, the thrid party will need to write some code to authenticate to our Azure AD and view this HTML content non interactively (Which means without allowing the third party app to prompt to enter user credentials from Azure AD).
Per my understanding, you could leverage the OAuth 2.0 Client Credentials Grant Flow by using the client_id and client_secret.
Also, you could use OAuth 2 Resource Owner Password Credentials grant. Note: The resource owner password grant doesn't provide consent and doesn't support MFA either. Detailed tutorial, you could follow here.
Based on the authentication implementation part in your Web App, you could follow the approaches below to implement your scenario:
For using App Service Authentication / Authorization
You do not need to modify any code in your Web App project.
For using Microsoft.Owin.Security.OpenIdConnect middleware
You could use Microsoft.Owin.Security.ActiveDirectory package in your Web App for supporting AAD bearer token authentication, and this middleware need to be configured before the other authentication middlewares as follows:
app.UseWindowsAzureActiveDirectoryBearerAuthentication(
new WindowsAzureActiveDirectoryBearerAuthenticationOptions
{
Audience = "{the-AAD-clientId}",
Tenant = "{TenantId}"
});
//app.UseCookieAuthentication
//app.UseOpenIdConnectAuthentication
For the client (the third Party), they could leverage the above two flows (Client Credentials Grant Flow ,Resource Owner Password Credentials Grant Flow) to retrieve the access token without user interaction. Then they could access the specific view page by using the token as follows:
Get https://{your-app-name}.azurewebsites.net/home/index
Header Authorization:Bearer {the-AAD-accessToken-or-IdToken}
For retrieving the token, you could follow this tutorial for using User Password Credential flow. For Client Credential, you could just construct the ClientCredential instance when invoking AcquireTokenAsync for getting the token.
Additionally, you could create a new AAD application for this scenario or just use the AAD application for your current Web App. Moreover, there may exists risks when exposing the username & password or clientId & ClientSecret to the third Party, I would recommend you expose a new endpoint for generating the token in your Web App backend and return the token to the third party for security consideration.
I'm looking for some guidance on what people think are the best set of technologies to use. We are looking to create a web portal to allow customers to register/login with standard credentials or their social accounts (Google, Twitter etc).
Once they are registered and logged in to the portal they can access our different web apps which will know who they are and what permissions they have based on a token. We will also need to secure a set of web APIs using some sort of OAuth mechanism, so the user would possibly create an account on the web app and then create an application which would give them the keys they need to access the API from their own app.
We have a basic portal app using MVC 4 and DotNetOpenAuth which allows a user to create an account and login with either a username and password or their Google, Facebook account etc.
The APIs would be MVC 4 Web APIs
Ideally the whole set up needs to be as simple as possible, I've briefly looked into using Windows Azure Access Control (ACS) as a way to cut out some of the heavy lifting but its hard to tell where exactly it all fits together.
Currently we run an ADFS 2.0 server and WIF to allow web login to our apps but it doesn't seem like it would be an ideal choice when integrating the social login and for securing the web APIs
I guess it could be two quite seperate parts, once they are logged into the portal, how would we go about providing some sort of claims token to the other apps they then access to understand who the user is and what they are allowed to do. And maybe the web API authentication/authorisation is its own entity?
Thanks for your time
We ended up using the built in MVC 4 login system and also added JWT token support, when a user is logged in a JWT token containing their claims is stored as a cookie. This is then automatically passed around our sites on the same domain by the browser, when the web API is called from javascript it checks for the token in the headers sent by the browser and either validates it and returns the correct data or returns an unauthorised response.
It doesn't cover all the bases, we can't give trusted third parties access to our web services yet