After a lot of searching, most of the scenarios moves all the authentication to Azure AD and WebAPI just has to know how to read the token. (To achieve this we are using Azure AD middleware in OWIN pipeline). Also, this means that any client that wants resources from the WebAPI has to authenticate to Azure AD on their own (For example: adal.js for JS). Lets say my I want to keep user info within my WebAPI. I suppose I can easily just Create/Read users using some unique field in Azure AD JWT token and I do not need to worry about token validity or any other stuff about security since this middleware does that for me. Simply, I can just use it.
And here comes the mystery that I can not understand.
What if my WebAPI requires specific claims that Azure AD does not provide. For example authorization (permissions and so on) or even organizationId (in multitenant application).
Azure AD works as external identity provider, same as Google, Facebook and so on. But the difference is that most of user authentication logic lives in WebAPI (at least with the examples you can find). Client application receives a list of external providers a WebAPI supports and that is it. This gives an opportunity to introduce LOCAL AUTHORITY tokens with the claims WebAPI would need. But it kind of means that you start creating your own identity service within WebAPI, you also have to manage refresh tokens and so on.
Does it mean that the proper solution would be to start using IdentityServer that integrates variety of external providers and manages token creation with specific claims that my WebAPI would expect?
Related
We have a SPA (angular) deployed which authenticates against an azure AD B2C and retrieves tokens that are then used to call some rest APIs.
Now I've been asked to call some other APIs (not under our control) protected by another azure AD B2C (again, not under our control). I don't think that there is any way to "federate" the two AD B2C.
Moreover I don't know if there is a way to obtain access tokens from an AD B2C using some hidden credentials (let's say a technical user/password defined on the second AD B2C) which I wouldn't use in the SPA for obvious reasons but then I could use my authenticated APIs as a proxy to obtain the token from the second B2C and then call the external APIs with the obtained token.
Am I missing something or I've been asked something not feasible with Azure AD B2C?
Your SPA can't easily have a direct security relationship with 2 independent Authorization Servers (or sets of APIs). Sounds like there are some security boundaries here that would be better managed by your back end APIs, which can keep secrets, unlike your SPA.
A useful pattern sometimes is to design 2 levels of API such as this:
Online Sales SPA is running for a user in Western USA
The SPA calls an Online Sales (Entry Point) API hosted in Eastern USA, 3000 miles from the end user
The entry point API aggregates calls to core APIs with low latency, since they are all hosted next to each other
The entry point API can also deal with security boundaries, such as forwarding calls to the new set of APIs
Personally I like your proxying suggestion, but I would not do it in a Core Microservice - I would instead assign this responsibility to an Entry Point / Aggregate API as above. This results in an extra layer, but only requires simple code, and you avoid adding complexity to any other components.
The only solution I've found would be having the supplier of the second azure AD B2C declare a new app registration in their B2C and:
under "Certificates and Secrets" they would add a new Client secret (which they would share with us and that would need to be recreated at least every two years)
under "API Permissions" they would need to specify which APIs (via scopes) can be accessed with the tokens generated using the client secret above
Then we would invoke our authenticated APIs (protected with the token obtained from our B2C via an interactive oauth flow) and the APIs would act as a proxy by calling their APIs after we obtained the token via the client secret.
All this could be done with different API containers with an API gateway in front of them for a cleaner architecture so that our core APIs are separated from the proxy APIs.
Does anyone know a better solution?
We are using Azure AD for authentication and authorization. Our angular spa has been enabled SSO with Azure AD. We need to secure our backend
service and only allow API which has a valid jwt token.
What we have done so far is:
Registered our angular app in Azure AD.
We have configured spring microservice as a resource server and
application properties contain jwt.issuer-uri
spring.security.oauth2.resourceserver.jwt.issuer-uri=XXXXXXXXXXX-XXXXXXXXX-XXXXXXX-XXXXXXXXXXX
The issue is the token that we get from Azure AD is having an audience as "00000003-0000-0000-c000-000000000000" which means the token is generated for the Microsoft graph. I also tried accessing graph Api with this token and it worked. But what we want is to verify this token in our own spring microservice and grant permission
based on jwt provided.
To solve this issue I had to make some config changes in our Azure registered Angular app. I have added a custom scope api://<>/app and use
this scope while acquiring the token. Now the token is being validated in the backend and API working fine.
This config somehow works but doesn't seem correct to me. I am new to azure so am not sure how all things tie-up.
The new token which is now being generated has an audience as our
angular spa client Id. Is this correct? Shouldn't it be the backend
service? Any why it's getting validated by the backend with the
current configuration?
My understanding is that we don't have to register our spring
microservice with Azure Ad. I will just act as a resource server and
will decode the token provided by the angular app using the
issuer-url.
In case we need to register our backend services with azure AD then
would it be difficult to do the same for all microservices?
I have done all settings by referencing.
https://ordina-jworks.github.io/security/2020/08/18/Securing-Applications-Azure-AD.html
In some other links, I find a completely different config for setting up backend service. I am not sure which one is correct.
https://learn.microsoft.com/en-us/java/api/overview/azure/active-directory-spring-boot-starter-readme?view=azure-java-stable
Azure AD is a little confusing when following a standards based approach. I wrote a blog post on this a couple of years back:
You have already figured out that you need at least one API registration to work, to expose an API scope - so that you get usable access tokens
The generated id from the API entry in Azure then becomes your audience, as in step 9 of the article.
What we'd really like to do is this, so that we can do things like forward the JWT in microservice to microservice calls:
Get Azure AD to issue an audience claim such as api.mycompany.com that is common to all microservices
Issue multiple scopes in the access tokens, based on areas of data in microservices - as in this Curity doc
I would aim for a single entry in Azure AD to represent your platform of APIs. Then each microservice can use the same generated audience value.
Hopefully you can get multiple custom scopes to work also, though there are some annoyances here, especially when you want to use built in OpenID Connect User Info scopes, which Azure AD exposes via the Graph API.
We have a scenario where in mobile app(Xamarin Forms IOS APP) logs into the Azure ADB2C and generate a JWT token if the user is a valid user(user is configured in Azure AD B2C). We have a requirement where in, we need to generate a token based on the role i.e. based on the role with which user logs in, we want to generate a token and that token we are trying to use it in subsequent Web API calls.
Articles which we found out on this particular scenario was having web application as a client where in some mechanism of secrets were explained. In the mobile app client scenario, its not possible to have a secrets.
Followed the below mentioned article, but couldn't get any concrete information also
https://codemilltech.com/adding-authentication-and-authorization-with-azure-ad-b2c/
Any pointers on this particular scenario would be very much helpful to us.
Thanks!
There is no out-of-the-box support for RBAC / Roles in Azure AD B2C. However there are a lot of samples in the official GitHub repository. For example the "Implementing Relying Party Role Based Access Control" by this method you can add the groups to JTW token and also prevent users from sign-in if they aren't members of one of predefined security groups.
I am trying to have two applications(app1 and app2) in Azure
AD B2C, which is configured for Web api and another application that is configured for mobile app.
I need my mobile app to talk to app1, get the access token, using the app1's application-id and scope. Then use the access token got from app1 to communicate with app2. I enabled SSO in tenant level in the policies but it still says "Authorization denied" for the access token provided.
How can I reuse the access token got from one application to be used in another application.
We have been trying to get through this limitation (or function as designed for security) of B2C AD from weeks.
However, Microsoft does not support it.
We did not want to display MS login page to mobile user on mobile login screen (UX gets compromised). But MS says there is no way possible to avoid it. See response from MS on support ticket.
For more information: Azure AD B2C: Requesting access tokens
You will also benefit reading authentication scenarios supported. We are after something similar to this what they call "Daemon or Server Application to Web API".
In this diagram, Server Application = to mobile application in our case. However you will notice that in this scenario it is assumed that the user is already authenticated (via interactive flow).
We tried to act smart, thinking we can write a Auth web API which mobile will hit to obtain token and then pass this token to our business logic API (secured by B2C AD). We obtained access and refresh token somehow, however the test web app (mobile app) when pass this access token to our business logic API, it fails to validate the token. B2C AD comes fighting for it. Our analysis is not yet complete.
However, I am certain what we are trying to accomplish is not supported in B2C AD.
Hope this helps (I would actually advise you to look for other solution). I will be happy if someone can suggest a way to solve this obvious business problem.
I understand ACS is being phased out in favor of WAAD. As I prepare to delve into Azure for the first time I have a few questions. I already have an Azure account (linked with my MSDN account).
Under ACS, I would create a namespace for my application, configure it with Idps and claims mapping. I would point my application (a RESTful API via WebAPI2) to the ACS federation endpoint for my namespace.
Under WAAD, I've seen where I can add my own application. When I create the new application, is this creating a tenant in my directory? I dont see where I can register my Idp's and configure the Idp's for my relying party. In addition to authenticating via social networks (like facebook/google/etc), I'm going to want to write a custom Idp to hit against my on-premesis user store. Is this possible in WAAD? Finally when creating the application (tenant) in WAAD, its prompting me for a Signon URL. Isn't WAAD supposed to manage the signon, the way it did under ACS? when I defended a website via ACS, the user was redirected to the ACS sign in page, where they could choose from a list of Idp's for login. Why then, under WAAD, do I, the app developer, need to code a sign on page? I'm pretty confused about this.
WAAD does not replace ACS. WAAD is a single identity provider (IdP), whereas ACS can act as a Security Token Service (STS) for multiple IdPs, but is not itself an IdP. Think of ACS more as a broker that has taken some of the work out of integrating with some of the common identity providers out there (Facebook, Google, Yahoo, Live, etc) so that you as the application developer can code to one interface instead of multiple.
My suggestion would be to continue to use ACS as your single point of contact for federated identities and add WAAD as an additional IdP to those applications in your suite that require it. This is a pattern we follow in a number of our applications where we use ACS as the main STS and then expose one or more of the IdPs to an application depending on our needs.
As to your question about a custom IdP pointing to an on premise user store you might consider using Thinktecture Identity Server instead of rolling your own. You can expose Thinktecture Identity Server from ACS just as you would any other IdP in your suite.