In the "Scenario: Daemon application that calls web APIs" Microsoft says : "There's another common case where non-daemon applications use client credentials: even when they act on behalf of users, they need to access a web API or a resource under their own identity for technical reasons."
And that's exactly what I need. A web application with an authenticated to AAD user, but with an ability for application to make a calls to MS Graph with elevated permissions (more than user has).
There is an example under "Microsoft identity platform and the OAuth 2.0 client credentials flow" called "ms-identity-aspnet-daemon-webapp"
which is very close, but it uses asp.net.
Does anybody have a .net core sample code of the same?
Thanks!
Try with A .NET Core 2.2 simple daemon console application calling Microsoft Graph with its own identity. It will show you how to create the MSAL confidential client, acquire a token and use it to call Graph.
Related
Be warned possibly noob question ahead.
I'm a little unsure where exactly Azure AD or IdentityServer is supposed to fit in in the overall communication flow.
Here is a scenario that I often face.
Some "dumb" client (e.g. a Windows App that can't use external assemblies or some JavaScript in a web app) has to contact my Web API which will then contact other APIs or other resources.
If I want to try and implement either Azure AD or IdentityServer as a means of authentication and authorization in the Web API, I don't see that this can be done in any other way, than it has to be the Web API that communicates with Azure AD or IdentityServer as the client doesn't have the ability to do so due to the lack of required assemblies.
If this assumption is not correct, then how would I do this?
If it is correct however, then what means of security is there between the client and the Web API other than communicating over HTTPS when the client has to send it's credentials to the Web API, so the Web API can authenticate and authorize the user against either Azure AD or IdentityServer?
If I understand your requirements correctly, then you are able to change the client Windows app, but unable to add external assemblies to it? So you would not be able to add the ADAL NuGet package to it.
You can still use Azure AD authentication - it is possible, but not trivial, to implement the client code yourself.
Or you can, as you already mentioned, pass the user's credentials to the Web API somehow, and then use that to have the Web API do authentication towards Azure AD on behalf of the user. There is a sample app which shows how to use username/password credentials.
This however, goes against the whole OAuth/OpenIdConnect mindset, where your app should never know the user's credentials.
Here:
https://github.com/MicrosoftDocs/azure-docs/blob/master/articles/active-directory/develop/active-directory-v2-protocols-oidc.md
Be careful with trying to use the most recent version of the Azure AD endpoint (just don't use version 2.0, they shot themselves in the foot by excluding all Azure AD webapp registrations & by "securing" web APIs by making them only available to apps with the same appid - as far as I'm concerned, it's unusable until they fix those two issues) - see the "[!NOTE]" near the top of that linked page for the v2.0 limitations.
So we are using IdentityServer4 for our web applications, all is good.
We have a new requirement from a client to allow them to perform SSO via their ADFS system using WsFederations, we already provide this for another one of our older web applications that is not tied into IdentityServer4 yet.
Ideally we would like to tie WsFedereration into IdentityServer4 so it is in one place.
Does anyone know if it possible to use IdentityServer4, so we redirect to IdentityServer4, identity that this particular client (possibly via an alternative URL), then IdentityServer4 authenticates against ADFS, collects the claims (probably basic, e.g. email/username/etc) , and we then supplement them with additional claims for access, and pass back to the web application.
What I'm trying to achieve ideally is to not change the existing Web Application, and to sort the plumbing at IdentityServer4, and the Web Application wouldn't know or care if this user was IdentityServer4 only or
IdentityServer4 + WsFederation. This would be useful for other clients across our applications to easily integrate in the future.
Alternatively I could deploy another version of the Web Application that authenticates directly with my clients ADFS system. However this seems a waste of server resources/maintenance for just one small client.
I had a look at the external options (where you click google on or near the IdentityServer4 Login Screen), is there a way to automatically redirect to the ADFS without event seeing the IdentityServer4 implemented Login screen.
Is this possible?
Thanks,
Jon
This was released 2017, see the example at
https://github.com/IdentityServer/IdentityServer4.WsFederation
I am currently working on a solution that includes a multi tenant webApi which will be accessed by multiple clients, some of which i will be creating, some of which others will be creating.
Access to the api will be available via an ApiKey & Secret (enough for some resources) as well as username & password (for owner resources).
At the moment, the clients i have created (.Net MVC Web apps) have their own membership systems so what happens is the user of the client logs into the client system and the client system passes the login information to the Api to retrieve an authentication token.
The client membership system is really an unneeded abstraction. What i really want to do is have the user log directly into the api and the api pass back an authentication token that can be used from the browser as well as the .Net MVC client app.
My question is, what it the best way to achieve this. In my mind i seem to be struggling with 2 solutions.
1) Have a browser based login (ajax/AngularJS for instance) solution that calls the api to retrieve a token which then passes that token onto the MVC client where it will be stored (session variable maybe). Any future calls to the api that come from the .Net MVC client can pass the token on. This seems wrong to me though. I'm not even sure this is possible.
2) Utilise one of the OAuth flows so that the browser based login can call the API and retrieve a token, and the OAuth flow redirects to the MVC client which then stores the token for that user (again, in a session variable).
The Api was generated using the VS2013 WebApi template using Owin local accounts and is generating tokens via the ValidateClientCredentials and ValidateResourceOwnerCredentials flows, but i think i need to use one of the other OAuth flows for this scenario.
I understand that another solution would be to bypass the .Net MVC client code and create a completely browser based solution using knockout or AngluarJS but it's quite a complex system and i don't really have time to do this at the moment so i'm looking for a solution that would allow me to retrieve a token from the api that can be used from my .Net MVC client and ajax calls from the browser.
Any ideas, advice would be much appreciated.
thanks in advance. Justin
If you'd rely on Azure AD as your credentials store and authentication system, you'd be able to leverage a ready to use JS library that handles authentication, AJAX calls and session management concerns automatically: see http://www.cloudidentity.com/blog/2014/10/28/adal-javascript-and-angularjs-deep-dive/.
If you can't rely on Azure AD, the code of the library and samples mentioned above can still have value as a reference to build your own system - provided that the authenticaiton system you decide to use offers similar capabilities.
HTH
V.
I'm trying to write a C# console app that will register an application in Azure Active Directory. It should work just as the web application project creation wizard in VS 2013 when you Change Authentication and select Organizational Accounts in Azure.
Following the fiddler trace, I can see that it authenticates the user using wsfederation and an oauth2 token and then uses the graph.windows.net graph api to configuration the AAD directoryObjects service principal and application.
I have tried to use the sample Graph API app, but it requires the app be registered first so that I have the clientId (application id) and password (key) to send in the Acquire Token request using the Windows Azure AD Authentication Library for .NET.
I've tried using a bunch of the different Azure APIs but they all have my chicken and egg problem, I want to use an unregistered client application to register an application in AAD. I need to avoid Configuring Application Authentication and Authorization for the Graph API so that the user has no manual steps.
Does anyone know how Visual Studio does it, using just the user login with browser prompt or if there is a standard application id and password that can be used to access the graph API, like there is the standard login URL, https://login.windows.net/common? Some C# samples would be greatly appreciated.
This post does the Application creation, but requires a clientId and password, which I don't think I have.
You can't register a new application using the Graph API from an unregistered client. The only reason the VS2013 flow works is because VS2013 is already registered in a special way within Azure AD -- it's a first party application and has unique permissions. In my Fiddler trace, VS2013 uses a client ID of 872cd9fa-d31f-45e0-9eab-6e460a02d1f1. Technically you can use this client ID and the redirect URI of VS2013 to initiate sign-on with Azure AD. This still involves user interaction (the user has to authenticate via browser pop-up) so it doesn't meet your requirement for "no manual steps," but it's somewhat helpful for understanding the protocol flows and how registration works.
The bottom line is that if you want to call the Graph API without user interaction (client credential flow), the client needs to be registered with the proper application permissions.
I have several Silverlight, WP7 and ASP.NET MVC client applications Most allow anonymous access to the application but secure various features based on a user's credentials when logged in. All of the clients use a common back-end service application for data access and business processing which require the user's credentials for authentication and authorization.
We currently use Forms Authentication in all client applications and I'd like to migrate our architecture to use federated identity and a claims-based model. Passive federation is not an option.
I am looking for the following flow:
The user triggers the login dialog, enters their username and
password then clicks "OK".
Behind-the-scenes, the application calls an active STS service in
our existing service application for authentication.
The service is actually a federated STS and passes the call through
to the (active) IP_STS which may or may not be ADFS.
When the IP returns the token to the FP, the FP modifies the token
with additional claims from the server data store before returning
the token to the client application.
The client application maintains the token in memory for
authorization checks (in Thread.CurrentPrincipal, for example).
The client also passes the token when making requests to other
service operations in our service application.
These service operations will use the token to
authenticate/authorize the request.
This is a very different use-case from any of the articles and samples I've been able to locate. Can anyone provide some guidance and/or point me in the right direction?
It is my understanding from Dominic Baier that WIF doesn't currently support the approach we are taking. We've taken his suggestion and created our own custom STS that moderates authentication using the Provider model.
Unfortunately, the farther we got into this, the more we realized that WIF isn't flexible enough to satisfy our needs at this point. We stuck with the custom STS approach but are using our own transport and credentialling rather than the WIF tooling. Hopefully a future release will give us what we want.