We have a separate web application secured with Azure Active Directory that exposes some (internal) services.
Now we want to access these services from within our site, but this fails off course because of the authentication that is not yet done.
This site doesn't use Active Directory for authentication.
Is it possible to configure this site as a trusted client (through token, key) in the web.config? So that we don't need any code modifications?
Or has this to be done through code?
Kind regards,
It looks like you have a WebAPI secured using Azure AD (what you refer to as web application) and a WebApp (what you refer to as site) that needs to access the WebAPI. If this is indeed the case, you can register both the WebApp and WebAPI as applications in Azure AD (the WebApi is presumably already registered, as it is secured using Azure AD). Then, your WebApp can access your WebAPI using its own identity (client credential OAuth flow sample code) or on behalf of the signed-in user (auth code grant OAuth flow sample code).
In either case, the WebApp (site) needs to acquire an access token to access the WebApi and send this access token in the Authorization header in every call that it makes to the WebApi - this will require code changes to the WebApp. In theory you can build a proxy application that acquires tokens and injects headers in all outgoing calls - however I doubt it would be worth the effort.
Hope this helps.
Related
I have this legacy intranet app using an AngularJS SPA consuming an an ASP.NET Web API (on .NET 4.6.1) and I can't manage to get the user authenticated on the domain inside the API, when calls are made by AngularJs.
Inside the API I have situations where I need to get the domain authenticated user. I have tried several combinations inside IIS to set both the AngularJS app and the API with Windows authentication, Impersonation, Authorization Rules. I've read several questions in Stackoverflow and other forums and also searched through several articles but I can't manage to find a solution, I'm feeling helpless in this one.
When I make a direct call to the API using a tool like Postman or through Swagger, System.Web.HttpContext.Current.Request.LogonUserIdentity.Name shows the correct authenticated user.
When I make the very same call to the API but through the client, like loading a page that requests data from the API, the user shown in LogonUserIdentity, is the one set on the app pool.
The authentication between the client and the API uses bearer token.
Here's my current scenario:
IIS:
Windows authentication enabled for both the client and the API, Impersonation enabled for both the client and the API
Authorization rules for ASP.NET and IIS set with allow all users for both Client and API
Session state in-proc, using cookies and with UseHostingIdentity set to false on both Client and API
Both the client and the API are using the same AppPool, with integrated Pipeline, .NET CLR v4.0,
If there's more info to supply please let me know, I'll update the question with the required info.
I am developing an application and I have already secured the api that I developed on ASP.net Core with Azure Ad implicit grant for the front end side.
Can I configure client credentials flow for accessing the API via Postman so that I don't have to authenticate when using it?
It is not possible to implement implicit grant flow and client credentials flow in the same registered application. The reason behind this is client credentials flow require client-secret and implicit grant flow does not work with application having client-secret.
If you want to configure client credentials flow for above scenarion for accessing the API via Postman then please create a separate registered application in your tenant and expose the API such that you can access with postman.
Please feel free to ask if you need any more help :)
I'm following the guide and example provided by Microsoft here and I'm able to get the demo working, with the authentication happening in a console app, then making a request to a Web API with the correct token.
I'm looking to use this but the code in the console app would need to move to a Web App. Essentially: external server tries to access secure Web API, providing Azure AD username/password in the Authentication header of a HTTPS request. I pick up these credentials in the first insecure Web API, and attempt to authenticate the credentials against AD, obtaining the token. From here, I would then call the [Authorize]-protected Web API by making a request with the AD token.
At this point I'm using the same code from the example linked above, simply moving the code in the Console app up into the first insecure Web API controller, but I'm having no luck. I read on CloudIdentity that "You can only use those flows from a native client. A confidential client, such as a web site, cannot use direct user credentials.". Is this true? If so, is there another way to achieve my aim? I need to use the credentials as it may be likely that more services would use the API in the future, so each of these would need their own credentials to use that could be managed within Azure.
EDIT: In reading more around this, should I actually be aiming to use Client authentication, creating an "Application" within the Azure AD, and providing the client ID to each external service looking to call the API, to then authenticate with that, rather than credentials?
Yes, your edit is correct. The Resource Owner Password Credentials grant is meant to authenticate users, not applications. Typical use would be from an application that prompts you for username and password and then retrieves a token from Azure AD.
You can use the Client Credentials grant to get a token from Azure AD from a confidential client to call an API without user context. This flow requires that you register the application in Azure AD and generate a key (which will be used as the client secret). You can then use the ADAL library to ge a token from AAD as shown here.
I have created an ASP.NET application and an Azure-AD domain. Currently, I have the ASP.NET auth set up to hit the wsfed endpoint in Azure-AD. Everything works fine, but the problem is that this issues a SAML token and I need a JWT. From what I have read after much internet searching, I need to authenticate to the OAuth 2.0 endpoint of my Azure-AD domain. The trouble with this is that with everything configured the way it is, I always get back a 400 from this endpoint, likely because my config file is all set up for fed auth. My question is how do I configure my ASP.NET application so that it can talk to the OAuth 2.0 endpoint of my Azure-AD domain?
I need to use passive authentication.
Azure AD supports the OAuth2.0 flow that you can execute once the user has signed in using passive authentication, to receive access tokens to make delegated calls to WebAPIs on behalf of the user. You can use the Active Directory Authentication Library (ADAL SDK) to execute the OAuth flow. This sample application does exactly that: http://code.msdn.microsoft.com/AAL-Server-to-Server-9aafccc1
However, for your scenario, we recommend the OpenId Connect flow now, instead of SAML SSO + OAuth. With Azure AD OpenIDConnect flow, the Web Application receives an SSO token (JWT id_token) using which it signs-in the user, and also receives an auth code (OAuth auth code) that it can redeem for an Access Token (JWT access token) to access WebAPIs on behalf of the user. Azure AD provides an OWIN component that does this. This sample application should see you through: https://github.com/AzureADSamples/WebApp-WebAPI-OpenIDConnect-DotNet
Finally, refer to this help topic to find all authentications flows supported and recommended by Azure AD for your Web Apps/APIs and Rich-Client/Mobile Apps: http://msdn.microsoft.com/en-us/library/azure/dn499820.aspx
Hope this helps
I am trying to do something like this:
I have a MVC4 Web App and a Web-API service (hosted on two separate roles in azure)
Another role runs CustomSTS1.
The MVC Web App trusts the CustomSTS1
Now the customer logs into the site he is redirected to the STS login page.
Once logged in, he is redirected back to the MVC Web Site.
From this web site, the customer performs actions, which in turn invoke the web-API Service.
I have the SAML token in the web app, which I pass to the WebAPI service.
Now when I try to validate the SAML token at the Web API side, I get a
Message=ID1032: At least one 'audienceUri' must be specified in the SamlSecurityTokenRequirement when the AudienceUriMode is set to 'Always' or 'BearerKeyOnly'. Either add the valid URI values to the AudienceUris property of SamlSecurityTokenRequirement, or turn off checking by specifying an AudienceUriMode of 'Never' on the SamlSecurityTokenRequirement.
This is without the Web API service trusting the CustomSTS1
Once I setup the trust,
I am always given a HTTP 401: UNAUTHORIZED, whenever I try to make a HTTP Get request to the WEB API Service.
Now, My Question is, (I know that my current approach is definitely wrong)
How do I setup the Trust relationship with the CustomSTS1, such that the WebAPI service is able to do an ActAS on behalf of the user logged into the MVC site?
OR
Is this architecture wrong?
And is there another way to achieve this?
That approach is wrong conceptually. The MVC application should negotiate a new token for the Web API in the STS using ActAs. That's how it traditionally works for SOAP Services. However, Web APIs are moving away from SAML as it is a complex format that relies on different WS-* specs. OAuth 2.0 is becoming the standard in that area if you want to support SSO at that level.
Another approach is to establish an implicit trust between the MVC app and the Web API, so all the calls to the Web API from the MVC app are done through a more standard Http auth mechanism like Basic Auth using an specific set of credentials that only the MVC app knows. The info about the logged user in the MVC app is passed as additional information.
Regards,
Pablo.