I've been wrestling with how to simplify our WebAPI/Identity authentication for our current/future WebAPIs. I'm new at this, but I'll explain it the best I can. We started with a single WebAPI and setup ASP.Net Identity to handle the authentication and such. Then we setup another, and soon it will be 30.
The problem here is obvious - for every new WebAPI we have to plug in yet another MS Identity Authorization layer. In some cases just having a single, massive WebAPI would work, but in this case these are totally separate products (plus its bad design).
So we wanted to shoot for something like this:
But I'm having a hard time figuring out how each WebAPI would get User information so I could check roles and such.
I've read many posts on WebAPI authentication such as: this this and this but it seems everything I find has to do with securing that SINGLE WebAPI and we know how to do that already. It feels like what we need is an SSO approach for our WebAPIs. It almost seems that we need something like the External Authentication approach (like Facebook, Twitter, etc) but using our own backend DB - I just don't know the proper terminology.
So I'm turning to the experts for help in getting me headed the right direction:
Is it common practice to have each WebAPI have it's own authentication/authorization layer that each point to the same DB?
Is the single auth layer concept built in to the WebAPI/Identity already or do I have to do it from scratch?
Is an Authentication Filter what we should be using?
I could hack it all together behind the scenes, but it feels like there is an obvious answer out there that I am missing.
Is there a built-in way to setup a "Trust" between each WebAPI and an Authentication API to do something like this:
This is the direction we are currently heading:
If I could just get a general push in the right direction, I'd be pleased as punch. I just don't want to reinvent the wheel.
Oh, and before I forget, we are using asp.net 4.5, WebAPI 2, Identity 2, on IIS
Thank you for any pointers.
What you are looking for is Federated Identity for your own web apis and is something that Thinktecture's Identity Server aims to solve. The documentation is probably the best place to start
Not to give too simplistic an answer but couldn't you just build an API as a fasad around the others. The top level API handles all of the authorization and then forwards calls to your other API's. I'm not an architect but that's what I would do.
Related
I would like to write a SPA application in React that will communicate with the .net core API.
I think it would be easier to have two separate projects (API + UI) on different domains.
API should be protected, that only authenticated users could make requests.
In react i'd like to have login and registration forms that will allow me to register and login users, and also I would like to have social providers. I would like to create whole UI for managing users in react SPA, and saving this data using API.
I did a lot of research, and I'm a little confused.
I would really like to use Core Identity because it simply looks like made for it
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity?view=aspnetcore-5.0
it has a ready to go model of Users, Claims, Roles etc.
it has built in services for managing passwords, users, roles etc
it has features to customize authentication schemes, policies, roles etc,
there are lot of reasons why i think this is a good solution.
Unfortunatelly, on the documentation site there is an information that for SPA integration it works combined with Identity Server.
https://learn.microsoft.com/en-us/aspnet/core/security/authentication/identity-api-authorization?view=aspnetcore-5.0
Last year I went throug every episode of this tutorial https://www.youtube.com/watch?v=Fhfvbl_KbWo&ab_channel=RawCodingRawCoding (btw. great tutorial), and I'm pretty sure, that I don't want to use Identity Server 4 for this scenario. As far as I know - this is the best solution when you want to have SSO for multiple applications, and you would like to provide one common way to authenticate user for all of it. And it has it's own UI for managing user registration, login and managing. This is not what I need - I just want to have it all written in React, cause I want all application to have the same mui theme without redirects to Identity Server.
But maybe I'm wrong, and Identity Server will work for me. But I found it to be quite lot of work to provide my own UI rather than MVC
(https://medium.com/#piotrkarpaa/using-spa-react-angular-ui-with-identity-server-4-dc1f57e90b2c)
For now I think, that I should use Identity Core on the backend, and communicate with it from React SPA with custom controllers like in here:
https://www.c-sharpcorner.com/article/authentication-and-authorization-in-asp-net-core-web-api-with-json-web-tokens/
Authenticating React SPA with API with JWT token - I think that this will work according to this example:
https://www.youtube.com/watch?v=FSUa8Vd-td0&ab_channel=Geek%27sLesson - but in here this is without Identity Core.
But I'm not sure that this is the best approach, and I don't know if I will be able to add Social Providers this way.
Also, I found serveral tutorials how to comine React App with .net core backend (and authentication) like this one:
https://www.red-gate.com/simple-talk/development/dotnet-development/integrate-create-react-app-with-net-core-5/
but I would like to have two separate applications, API and UI.
What is the best approach to achieve this goal?
EDIT:
Few months later, I already have SPA application, API and IS4. There is lot of problems to make Identity Server views (registration, login etc) look similar to SPA Application. (React app in MUI, MVC with bootstrap... ).
Now I think it was a bad decision, causing lot of problems:
2 way integration of users from API and Identity Server 4
changes in SPA layout, styles, colors - it all needs to be maintened on Identity Server 4 too
Bad user expirience - editing user profile on another application, on another domain with slightly different styles
Now I'm about to rewrite application, not to use Identity Server 4. Components for registration, login and editing user profile will be in SPA application, maintaining users will be done using API.
The only think I do not know is how can I use social providers with this aproach?
My question is still remaining without answer, can someone help me with providing proper solution?
Finally I found proper solution for me:
https://mahdikarimipour.com/blog/google-auth-for-react-with-aspnet-identity
thank you for your post: Mahdi Karimipour
I am working on learning the basics of Asp.Net Web API and started to tackle the area of authentication. After doing some research it seemed that the right direction to go was OAuth2 and JWT so that is what I started to learn.
I have now ran through several tutorials, the final one being here which I found to be incredibly informative.
At this point I have a functional authentication server that issues JWT and a Web API endpoints that consume the tokens and even authenticate based on roles defined in the tokens. I feel that I have a solid understanding of the basics but it has left me with a questions that I haven't been able to find good answer to.
How do you handle a Web API that manages permission sets for multiple objects? A good example would be GitHub and repos; I could have different roles for each of the repos I have access to.
Originally I thought the solution was to just place a claim in the token for each repo with the permissions for that repo but it is possible for me to be a part of 100s or repos, that would have to result in a fairly large token.
I also considered a hybrid approach where put the claims in the token until a user belongs to some number of repos, say 10 for example, then I just put an indication in the token saying I need to query the db for the list of permissions.
I suppose both would work but neither of them feel right. I was just wondering if there was a best practice for this kind of use case and I'm sure someone has answered this before but I was having a hard time coming up with the correct search terms to get the answer. Thanks for any help you can provide.
I want to guard OData service with custom authentication associated to a user table in database. I have been obssessed with this problem and searched solutions for a long time in vain. I mean, yes, there are quite a lot articles on the web but they are just quite trivial, for example implementing IPrincipal or IHttpContext with basic authentication on. Notably, many of them can data back to 2010 where OData is not as mature as today. So I'm wondering if there is any rapid solution to database-based custom authentication.
Any guidance would be greatly appreciated!
OData and authentication (and even authorization for that matter) are unrelated for the most part by design. That doesn't mean that OData stacks can't provide good support for authentication and authorization, just that the OData protocol itself doesn't comment on it. Protocol aside, both Web API and WCF Data Services are working on getting better support here. Speaking as a member of the .NET community (and not as a Microsoft employee), I think it's reasonable to expect that as those stacks implement authorization APIs they will probably be looking to claims-based authorization. Again, I want to state explicitly that I'm not trying to hide or divulge any plans here - I'm merely speculating about where authentication and authorization are going.
In a nutshell, if I were in your shoes I'd find the easiest intersection I could between OAuth2 and claims-based authentication and make that work for now. Working out your claims and authentication now means that you only would need to consider integrating the actual authorization code later.
It should be possible to use SAML to authenticate users for any type of application (according to the spec), but the examples I have seen are cookie-based ASP.NET web-sites.
Does anyone know of an example authenticating users for, say, a Win Forms app (not using cookies)?
Not quite sure what it is you are looking for. If you are looking for SAML based authentication, you can use some combination of Windows Identity Framework and WCF and AD FS. SAML is just the "language" of authentication, but unless you already have an identity provider, you need to start there first.
You can use this article to give you an idea of what the basic infrastructure looks like, and I frequently use the site leastprivilege.com for a deeper reference.
But, if the scope of your application is purely within the desktop (ie, never communicates with any services) you really don't need anything like SAML to achieve your goal. Usage of tokens like SAML are for communicating with web services where the endpoints trust the identity provider.
SAML is a wee complicated beastie. I'm not sure I'd try to roll my own SAML SSO solution.
When we implemented SAML SSO, we used PingFederate from. It's expensive, but good. There's also some open source SAML SSO stuff about, but I can't really speak to it.
PingFederate is pretty dead simple to configure and use, although if you don't speak SAML, the learning curve will be steep until you understand the concepts, the flow and the lingo used.
I am relatively new to the WCF world so my applogies for the newbie question. I am currently designing a layer of WCF services. One of them is an authentication service, so I came up with the following authentication mechanism:
IUserService.TryAuthenticateUser(string username, string password, out string key)
Basicly the user tries to authenticate and if successful - he/she receives a sessionkey/securitykey/whateverkey... the key is then required for every other "WCF action" e.g.
IService.GiveMeMyFeatures(string key);
IService.Method1(string key);
This mechanism looks extremely intuitive for me and is also very easy to implement, so what bothers me is why I cant find similar WCF examples? This unique key (which is practically a session key with wcf-side expiration and all) can then by used from the various applications, according to the application's architecture: for ASP.NEt it can be stored in a cookie, for Winform/WPF/Mobile I guess it can be stored in the form-class in a field and so on...
So here comes question number 1: What do you think of this method?
I also read, that I can use the build-in ASP.NET Authentication Services (with membership providers etc... if I understood correctly). From architecture point of view I dont really like this method, because when authenticating from an ASP.NET page the workflow will be like this:
ASP.NET -> WCF -> ASP.NET Authentication Service -> Response
In this scenario one could also bypass the WCF layer and call the auth. service methods directly from the asp.net page. I know that by going thru the WCF layer for every authentication request I will lose some performance, but it is important for me to have a nice, layered architecture...
And here is question number 2: What are the advantages/disadvantages of this method over the first one, and why is it so popular, when from architecture point of view it is kinda wrong?
I also read, that I can send user credentials for every WCF method call and use the built-in mechanism to authenticate and respond properly to the request.
Q3: What do you think if this method?
And to sum up - obviously there are many authentication methods, but which one do you think is best and most generic (considering that the WCF services will be called from asp.net/wpf/mobile/etc...)?
Thanks is advance :)
The reason you can't find examples it's not best practice - it's turning something that should be stateless, web services, into something stateful, and something that will not load balance well at all.
As web services already have standard username and password facilities, supported by almost every SOAP stack (excluding Silverlight) that's the way to go. You can use the standard .NET role based security model to protect your methods with this approach as well.