I'm building a MVC website (with EPiServer) that I initially set up with a custom membership and role provider that call a REST service for user validation and permissions.
However, it seems we could benefit by changing to Microsoft's Asp.net Identity v2 for claims based auth. But I'm having trouble figuring out how to arrange Asp.net Identity 2 to use the same REST service for user validation and generating the claims. Most examples on the web are specific to using OWIN and Entity Framework which don't seem relevant for what I need.
Could someone point me in the right direction to figure out how to utilise Asp.net Identity v2 but with integrating our REST service for the user validation and permissions/claims? I feel that I should only need https://www.nuget.org/packages/Microsoft.AspNet.Identity.Core and to make a custom UserStore that talks to the REST service, but I'm not confident due to lack of clear examples or documents (or maybe it's just me) to implement it.
Hope this is a clear question - let me know if there's anything other info that could help improve the discussion.
Related
I work for a company that supports many applications, but for ease for users has an OAuth OIDC Single-Sign-On (IdentityServer4) so they can log in once and access many applications of ours. I have no problem configuring authorization to this OAuth with the returned JWT/Access Token.
But because our support footprint is so large, we have been told to handle roles, and user permissions at the application level. Here is where I am asking for feedback. I am currently developing a new API in .Net Core 6 (newbie to building APIs), and am wondering best practice for connecting a essentially third party OAuth, but also utilizing roles and permissions specific to the application.
The Identity Server returns a JWT/Access Token that is passed to API in form of bearer, but I need a mapping on the .net core backend to map the User contained in the JWT with a user within the application. Then the application can have separate mappings for roles/permissions, and utilize those roles as restrictions within the API, but I am not sure what best practice would be for this that also maintains the best security, while also achieving best performance. My thought was creating a middleware that creates and overrides userIdentity, but with that happening each call seems like unnecessary overhead. The other option is dual auth with cookie based auth that is set once, but am just unsure of best way, or what others have had success with. I know this must be a common flow that I am overthinking. Any insight is greatly appreciated.
It is common in many mature business systems to integrate identity and business data as you describe. There are two main techniques:
Identity system reaches out to business data at the time of token issuance, to get custom claims to include in access tokens. This Curity article explains the approach.
APIs look up custom claims, eg from a database, when an access token is first received, then cache custom claims for subsequent requests with the same access token. See this .NET code of mine for one way to do this.
In both cases the end result should be that the API business logic gets a useful ClaimsPrincipal that enables the correct authorization, as in this example class.
Finally, from an information disclosure viewpoint, aim to avoid returning detailed claims in JWTs to internet clients. It is common to use opaque access tokens instead, as a privacy preserving pattern.
Migrating an SPA web app (Angular) and ASP Core Web API from Auth0 auth provider to Identity framework due to some requirements and limitations.
Until now everything was handled by auth0 and I didn't give it a much thought about the whole process of authentication. I would simply redirect users to auth0 hosted login page where it'd handle everything, callback with access token and I would use it for calls to API where API would just verify the JWT.
Now that I need to do this all manually, I am a bit confused. I want to have multiple authentication options: either Email/Password or OIDC auth providers like Google/Github.
I can get access token from these OIDC providers without much problem. But what do I do exactly with it, or to be more precise how do I configure Identity framework to handle the rest, without doing a lot of manual work? All users have quite a bit of additional data inside Identity framework user classes and I'm not fully sure how do i connect that to OIDC tokens.
Sorry for a bit abstract question, I think I'm missing some small detail, but at the moment I'm just really confused.
A lot of this is in place already, so to test the OIDC tokens, you just need them to be accepted by your consuming API.
To do so, you need to do some configuring, probably the same as you did for Auth0. Since the dependency here of the external providers, I'll post a link:
MSDN Google Auth
To accept them, you'll need the following steps:
register your API with the exteral provider
use the, provider dependent, instructions to set it up in your API.
The providers are additional to the one you have in placed and are referenced by Identity as ExternalProviders
In general, it's pretty easy. Possible some things are left out, since I don't know your exact use case.
So you are using an Identity Provider, previously Auth0, and now another (or custom) one.
Just for sanity a recap of your use case:
You trust the Identity Provider so every token signed by this provider is valid.
Your Identity Provider (and the external ones e.g; Facebook, Google etc) are responsible for their own user management.
Your own Identity Provider needs to handle specific authentication methods, tested against a corporate UserStore. These need to be managed, possibly with AD, Identity username/password or something similar.
Your Identity Provider provides authentication through JWTs
You also want to use external Identity Providers like Facebook etc.
So, as for the setup, you must do the following:
Implement (or reuse, or use ActiveDirectory or any other) user management tools, if you need to perform some management on them. This means password recovery and all that stuff, which is available in a lot of standard libraries (I think it comes out of the box in Identity)
Define clients, scopes and claims throughout your system(s). Possibly there is some effort to be made.
Make sure the JWT's are accepted as authentication throughout your system (this was already in place) and the proper claims are assigned when called for the correct client.
Register your API with the external providers
Setup your API to accept the external JWT tokens (needs some setup with secrets and API keys)
A lot of this is already in place in the Identity framework. There is an article about it here.
If you are willing to do a good exercise (and a lot of work), you could also try to implement things fully customized with IdentityServer4
How to implement Asp.net identity for authentication and authorization using service stack V3 with SQL Server as back-end managing users, roles and membership
Microsoft's ASP.NET Identity provider provides a way to do Auth/Authz in ASP.NET code with a SQL backend. You can write your own provider if you are motivated.
ServiceStack's built-in AuthProvider provides it's own independent way to do Auth/Authz over ASP.NET with a SQL backend. You can also write your own provider.
The two do not share any code, models, or interfaces.
If you want to implement the ASP.NET Identity model using the ServiceStack AuthProvider model, you would have to customize the ServiceStack provider with code from the ASP.NET Identity provider.
To customize ServiceStack AuthProvider v3, try my blog post:
Customizing IAuthProvider for ServiceStack.net – Step by Step
Then you could stick in the ASP.NET Identity code. The articles ASP.NET Identity Stripped Bare - MVC Part 1 ( #dr-net mentions) will show you what you are in for.
You would have to decide if its worth it - you probably want to just pick one or the other, instead of trying to mash them together.
FYI- the ServiceStack v3 and v4 Auth code are somewhat different - at least some refactoring done.
I have been going around in circles trying to properly understand this.
I have an ASP .Net MVC project I am working on and need to implement user logins that authorize and authenticate against en external system (via webservice).
I can't seem to get my head around MembershipProvider and AuthorizeAttribute in the context that I require.
Which do I need to use (I believe its both) and where do I need to customize to provide the authentication against an external system.
There is one additional thing I also require on top of the default ASP .Net user principals in that the external webservice will return a session ID upon successful login that would be used for subsequent requests to external services.
Would someone be able to point me in the direction of some useful example of this sort of set up?
MembershipProvider is used to provide the users that may login the system. The RoleProvider is used to tell which roles a user has. They are used during the authentication process. i.e. identifying the user. You can read about membership vs roles
The [Authorize] attribute on the other hand is used during authorization. i.e. to check if the user is allowed to do something.
I have an existing production application that uses vanilla ASP.Net Membership for authentication.
However, I'd like to provide other means of authentication as well as the current ASP.net membership system, such as Facebook.
The Windows Azure Access Control Service makes this extremely easy and straight forward. Provided, that is, you're starting a new web application from scratch.
So, in this case, how do I
Integrate the Access Control Service authentication into my app without affecting the current login system and its users?
Migrate users over or Link logins? ( not sure if this is even possible)
Thanks all
Roberto
You need to create a custom identity provider based on your membership database. See this article on custom WS-Federation Identity Providers that can be integrated to access control: http://msdn.microsoft.com/en-us/library/windowsazure/gg185933.aspx
Also see this article on one that was written on top of the membership database: http://blogs.msdn.com/b/vbertocci/archive/2009/04/23/enhance-your-asp-net-membership-based-website-by-adding-identity-provider-capabilities.aspx
Approach of creating an identity provider (IP) based on your ASP.NET membership database which Paul Tyng suggested is valid.
However, it means that if you just create an IP you'll allow log in to all people who are authorised with other IPs (e.g. Google or Facebook). I'm guessing it's not what you want - you'd still want people to first register (either plainly with username-password or with their external identity). If that's the case then your task is the following:
Add a data store for users' external identities which is related to your existing Users table.
Modify the ACS login handling within your application to check that the identity returned from ACS actually exists in your members database.
Perform member log in (instead of federated log in) if you found the returned identity in your db.
Add external identity tie in during the registration process so your Identities table can be actually populated.
(optional) Re-use the bulk of the #4 mechanism to provide an ability to attach external identity to existing user accounts (i.e. I already have a normal membership with you and now want to add an ability to log in with Google as well, for example).
There is no one single tutorial/walk-through to achieve this (or I have not found one) so I had to pull bits from a variety of sources to make it work. Please let me know in the comment if I understood your requirement correctly and I'll add a guide on how to set this up. Cheers!
Might be a bit late, but check out the following blog posts by fellow Windows Azure MVP - Dominik Bayer:
Mixing Forms and Token Authentication in a single ASP.NET Application
Mixing Forms and Token Authentication in a single ASP.NET Application (the Details)
Replacing ASP.NET Forms Authentication with WIF Session Authentication (for the better)
Invaluable readings which will help you in any way!