After a lot of reading and trial and error I got my target design working:
IdentityServer4 (standalone with AspNetIdentity) with IdentityUser database
MVC Client (standalone), this is the frontend to the users, no database link at the moment
1-n WebAPIs which serve the functionality to the MVC Client and have their own databases
At the moment I use an already existing IdentityUser database and point the IS4 to this database, added roles and claims manually for testing purpose.
My question is about best practice to register new users.
As the MVC Client is the frontend to the user, a link to the user registration should appear here.
But where is the registration technically done?
Should I do it in the MVC Client (with the default IdentityUser Registration) and point the database to the IS4 database or
should I add a register function in the IS4 app to keep the MVC Client free of any database dependencies and point the MVC Client "register" link to this IS4 register function?
Basically IdentityServer has two responsibilities:
Authenticate the user
Authorize the client
The 'problem' with IdentityServer is that the user is not restricted to one application. While the MVC website may be your front, IdentityServer does not relate users to a particular application. Once authenticated, the user can access all applications that use IdentityServer as an authentication server.
So does it make sense to register the user on the MVC website? Probably not, because the user can access the (future) 'mvc2' website as well.
The creators of IdentityServer acknowledged this, so they created the PolicyServer:
We think that tightly coupling "Identity and Access Management" in a
single solution is the wrong approach. These two concerns should be
clearly separated.
In other words: authentication is part of IdentityServer, authorization (of the user) is not.
Getting back to the question, registration of the user should be managed by IdentityServer. Because that is the only application that has access to the Identity store. Besides, users can also register without being redirected by an application.
The key is how to manage the authorization (of the user). This isn't actually part of IdentityServer. I won't go into detail as this is outside the scope of the question.
But to answer your question, what I would do (including email verification, but without automatic login):
Add registration functionality to the IdentityServer and implement a ReturnUrl (like is already the case for login).
Add a link on your mvc website to the register function on IdentityServer. Let the user register in IdentityServer, send an email verification link which sends the user to the login page (persisting the return url), allowing the user to redirect back to the mvc website once registered and logged in.
How to add authorization to the registered user is a different question.
I would not use "User Management" and "User Registration" interchangeably. There is a lot more to user management than just registration. But to answer your question:
Should I do it in the MVC Client (with the default IdentityUser
Registration) and point the database to the IS4 database or
You could, and there would not be anything terribly wrong with that. This will heavily depend on your business requirements, but most often I have seen "User Registration" built into the identity providers (your IdentityServer4 in this case).
Related
I'm implement aspnet identity with my MVC5 project. I have configured my project to use cookie authentication, form authentication and external authentication (facebook and google). Everything work fine.
Now i have a requirement to log whenever user log in system and i need to do some further logic. For the form authentication and external authentication i have a controller action that i can add my logic. However for the case user just come back system via cookie, how do i handle it?
I'm sure there's a better way to handle this, but a basic method would be to track all activity by the user, and then use timestamps to determine when a user was last active on your site.
Discussed here: Track user activity/actions for an asp.net mvc website?
OnExecuting filters here: https://msdn.microsoft.com/en-us/library/gg416513%28VS.98%29.aspx
Context:
We have a monster ASP.NET MVC 5/Framework 4.5 application that is planned to be divided in several others, so each new application will deal with a specific business domain instead of many. All those applications together will provide the same functionalities and services that are provided today by the existing single application.
We plan to use our own OAuth server to provide authentication and authorization for all the new smaller applications, so the very same users that use the current large application will have the same rights in the same functionality.
Currently we use Windows Authentication mixed with a secondary custom structure to establish what a certain user can do. We have our own role provider to generate the roles assigned to the users. When a certain controller action asks for the list of roles af a certain user, our role provider search in our custom structure and provide those roles, following specific business rules that make sense in our application.
We understand that the same rules that establish the set of the roles assigned to a certain user will be moved to our OAuth server.
We understand that the role-based security will be replaced by a claim-based security.
We understand that we will stop testing for roles and start testing for claims.
We understand that the first step of this refactoring should be add external authentication in our current large application and then start to break it into parts so we will have our new ecosystem.
Question:
How to change my current large application so it authenticate and authorize requests by using the new OAuth server instead by itself?
Note:
I´ve read a lot of blog posts but so far I couldn´t find a simple code sample that shows me what to do to instruct my application to go for an authentication/authorization token in my OAuth server and use it to grant or deny the access to a given controller action.
I have an app that uses my own membership system. It uses ASP.NET MVC 3 which I'm updating to ASP.NET MVC 5. It's not possible to change the membership to use a new one like ASP.NET Identity. But, for the authentication side, do you think it is a good idea to replace my auth-ticket system with OWIN.Security? Are there any traps that I should know about?
The Katana security middleware is independent from ASP.NET Identity. You can use them both or just one.
There are some cases where it makes very good sense to use just the Owin/Katana middleware, but not involve aspnet identity.
I just rolled up a prototype webforms application using OpenID Connect against an Azure Domain. My domain is Federated with an on-prem ADFS. By the time I got OpenID Connect and the GraphAPI working, I realized that I didn't really need much from aspnet identity.
I use the GraphAPI to grab extra info about the user and their group memberships, and I am adding that info as claims on the user principal... my site's code can operate against just the information in the claims.
Of course, if you want to do any custom profile or role stuff in your application, it probably makes sense to link it to aspnet identity too.. create an aspnet identity user when a new user authenticates, map that user's AD groups to roles, etc. Then you can manage application specific data for the user directly in the application via aspnet identity, while relying on Azure AD for the core authentication, basic profile, and group/role assignments.
I'm working on an MVC4 site using SimpleMembership to handle user accounts and role based authentication. We have another site and we'd like to implement a single sign on system allowing users from the existing site to log in to the one I am building. What would be the best way to achieve this and hopefully leverage to the existing roles based authorization I'm using on the MVC4 site. Is it possible to have multiple membership providers (i.e. use the built in one and if the user is not found, attempt to authenticate via a custom provider that I'll write (once I work out how!). Or would it be better to abandon the built in membership/roles and roll my own?
I also thought of letting WebSecurity check the local database and if the user is not found, query the 2nd database and if the users credentials are valid, create a local account for them. One issue with this approach is if a user called Fred registers on the MVC site, and then a user from the other site called Fred logs in, we couldn't create them a local account with the same username. We could prefix/suffix the username with some text to indicate that they are from the other site but then we lose the single sign on feature.
We will also want to integrate AD authentication for staff in the future.
So essentially I'm looking for the best way to authenticate users from multiple databases and keep using roles based authentication?
I've also done a little digging was wondering if ADFS might be useful for this.
Any help or advice would be greatly appreciated!
I recommend the use of an Identity server to handle all your login request and switching to a claim based authentication instead of a role based authentication if you can.
I personally went with Thinktecture IdentityServer
pluralsight.com have a good course on it.
Thinktecture IdentityServer is build on top of simple Membership and it supports multiple protocol such as
WS-Federation
WS-Trust
OpenID Connect
OAuth2
ADFS Integration
Simple HTTP
I recommend checking it
Good Luck
I have reviewed some of the similar questions on this site but could not find one with an answer appropriate for my situation.
I am using asp.net mvc, and it is communicating securely with stateless wcf services. for each service call, i need to pass in the username and a few other ints for identification purposes. - not password, the services are not authenticating.
I am using forms auth to authenticate the users. I am just not sure where, after the user logs in, I should store their username and other account details used for the scope of the user's time logged into the site. suggestions for webforms apps include in "Session". Is there an equivilent alternative in MVC? is storing the info in the forms auth cookie the best solution? it seems like it would be slow to have that info in a cookie as opposed to somewhere else in memory..
thanks
If you need access to a select few bits of information about the current user over and over again, you could combine FormsAuthentication with a custom principal implementation.
The Forms authentication mechanism will write a cookie to your client's disk, and will recreate the custom principal based on that cookie for each call. You could e.g. store something like a user "level", a user "profile" or other small chunks of information, which would then be accessible through the HttpContext.Current.User at any time during the lifetime of your request.
Check out these resources on the topic:
MSDN docs on How to Create a Custom Principal Identity
Using Custom Principal with Forms Authentication in ASP.NET
and I'm sure googling or binging for "ASP.NET custom principal" will render quite a few more hits for you!
yes, unless it's a lot of information, the preferred location is to store it in the cookie. Aside from that, session is the next best place.