I'm in the process of trying to set up a server for a personal project. I'm using ServiceStack.Core with a Neo4j graph database as my persistence layer.
I would like to set up user authentication using my graph database as the user auth repository. There is no existing implementation of IUserAuthRepository for Neo4j as far as I can tell, meaning that I will have to create my own. Unfortunately, I have found very little documentation on this interface and how to correctly implement it.
So, I have a few questions:
Does there exist any kind of tutorial or other documentation on how to correctly implement my own IUserAuthRepository?
The CreateUserAuth method is supposed to take a password. What if a user logged in using Facebook or some other service and does not have a password?
Would it make more sense to just use Redis for authentication (with RedisAuthRepository), using the userAuthId to look up users in my graph db? Are there any major pitfalls to doing something like this? If I do go this route, how do I hook into the registration process to ensure that I create a user in the graph DB whenever a new user is registered?
There aren't any docs on implementing IUserAuthRepository, it's an interface with a lot of reference implementations. Easiest way would be to follow the implementation that works similar to neo4j.
The IUserAuthRepository stores 2 tables, UserAuth master table and UserAuthDetails child table which is where all OAuth providers like Facebook maintain info received when authenticating with them. The password field is used for CredentialsAuthProvider.
You can handle different events during registration and authentication with the Session and Auth Events.
Related
I'm mid-way through a task to migrate a legacy .NET MVC app to use Single Sign On (SSO) to make integration with a to-be-developed mobile app possible. I'm planning on using Azure AD B2C to facilitate this and based on my researched, I need to use custom policies to achieve the required functionality.
Work on this migration is proceeding very slowly. I'm finding the custom policy XML very clunky to work with. It's going to take quite some time to achieve parity with the existing system given the current velocity. I'm wondering whether it would be wise to sidestep a lot of the migration headaches by using the Microsoft Graph API in place of custom policies.
Take registration for example. It appears common to redirect the user to a SignUp.xml custom policy (or the integrated SignUpOrSignIn.xml) to handle adding the user record in the AD B2C data store. Part of this policy would involve calling a REST API to create a corresponding record for this user in the app's database (stores email settings and such). Instead of using these custom policies, my plan would be to instead take the existing registration process and simply add a step which creates the user record on the B2C side using the Microsoft Graph API.
It appears like most things I need may be achieved using the Microsoft Graph API. Things I'd need that I can see are not available are:
logging in to a user account and;
sending verification emails
Are there any other common authentication-related tasks I'm likely to need that couldn't be achieved using the Graph API?
As far as downsides, the fact I'd be handling user passwords (even if it was just to create the user and nothing else) is an obvious concern, but perhaps acceptable. The main thing I'm after is a simple SSO solution that generates secure access tokens (incl. handling reset tokens, etc). I hope then, that this could be a feasible option.
You will miss out on password reset, profile edit, SSO and token expiration etc.
A better way may be to use the base custom policies and achieve a lot of what you need by having the policy call REST API's.
What is your use case?
We are starting a new ASP.NET Core web site and the customer would like to handle the authorization using the database. So they want to configure custom roles and the actions to be configured in the database.
I have been trying to find an example or something to help me implement this, but could not find. Can this be achieved using the Authorize attribute from framework or a custom filter needs to be implemented?
EDIT:
I should probably mention that the application is an intranet so Windows Authentication is used for authentication
Short answer Yes.
Long answer...
This can all be achieved from the database you can configure up using existing methods with Identity, and from there create all the custom roles and even policies that you want to have and be able to assign, to each user individually or via roles.. Authorize attribute will work just fine with cookies. My only recommendation is that you try not handle security yourself but let the framework handle this for you.
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
There is so much information and terms here I find it hard to start think about users. What options would I have for creating a user-based ASP.net MVC 3 web app? I've read of membership, providers, authorization, authentication, session, cookies, roles and profiles, but I can't seem to get a grasp on the big picture of how user-things are handled.
What are the pros/cons of using a built-in microsoft solution here? What is it even called?
Can I use my own database only (I want to work database first)?
In my mind I think like so: I have users and roles in a database. Users have roles. I want to deny access to some actions depending on if the user is logged in and has a specific role. Am I over-simplifying the issue? Where should I start?
At the moment I'm thinking of doing a 100% home brew system like when I was developing using PHP but since there's so much info I feel like that would not be a good approach here.
You want users and roles, i.e. you want to authenticate users and authorize them with privileges using roles. I would highly recommend not rolling your own, as you would in PHP. Instead, I recommend using the .NET "Provider" services -- specifically, the MembershipProvider (for authentication) and the RoleProvider (for authorization).
You can still use the Providers with your own db, they are not exclusive to or exclusive with code first. However, I would recommend NOT storing application-specific user information in the Provider's user or member tables. Instead, you can have your own code-first User, and link it to the membership system through the user's username.
The reason I recommend this is because it reduces the amount of work you have to do. You need not worry about encrypting or hashing passwords -- the provider does it for you. You have full API to control your users and roles through the System.Web.Security namespace.
As for Profiles, this is a separate Provider service that you do not need to use. It allows you to store information about users whether or not they have registered for a user account in your system. Technically you can have "anonymous users", but anyone who has created a password-based login is instead referred to as a "member".
Regarding cookies, authentication of a user in .NET is done through the FormsAuthentication class. After you have authenticated a user using System.Web.Security.Membership, you can call FormsAuthentication.SetAuthCookie to write their authentication cookie. This fully integrates both the User and their Roles into the Controller.User property, which implements the IPrincipal interface. You can use this object to get the user's name, and find out which roles they are in.
Reply to comments
I answered a very similar question here. Basically, it's up to you whether or not to have the membership in a completely separate db than your application, but I consider it good practice, because I have done this quite a bit and I have no complaints. Especially if you are using code first, since you can lose your entire db if you use the DropCreateDatabaseIfModelChanges or DropCreateDatabaseAlways initializers.
There is also a new membership provider. I think the NuGet package is called "ASP.NET Universal Providers", and they are in the System.Web.Providers namespace instead of the old System.Web.Security namespace. I haven't had a chance to work with them yet, but from what I gather, they are more compatible with code first. For one thing, the tables aren't named like aspnet_Foo, and there are no views or stored procedures created in the db. The table names are just normal dbo.Users, dbo.Roles, etc.
As for linking the provider users with your app (content) User entities, see the answer I linked to above. The easiest way to do this is to just have a field in your content db for UserName, and link that to the provider db's UserName. No foreign keys necessary, since you integrate them at the app-level, not the db level.
I think you should first start with built-in solutions, they're easy to extend if someday you'll need something more (even if to write a good providers for authentication isn't really trivial. Start reading this article, it's a good start point).
I don't think to write everything here is a good idea, it's a big topic and I should simplify everything too much so I'll post some links I found useful.
Just to start, with text from MSDN:
Authorization determines whether an identity should be granted access to a specific resource.
Authentication is the process of obtaining identification credentials such as name and password from a user and validating those credentials against some authority.
Imagine users and roles as Windows users and groups. For example a web-site for forums may have a user named AUser with following roles: User, Editor, Moderator. In that web-site they may grant a set of allowed actions: User may enter new posts, Editor may change posts of other people and Moderator may close or delete posts or topics. In this way single web pages don't need to know users but just roles (the DeletePost method of PostController may be decorated with [Authorize(Roles = "Administrator, Moderator")]).
Start reading this very introductory article, it provides additional useful links.
I have ejabberd set up using external_auth to authenticate against the user database of my web application. What I would like is to be able to create a MUC (chat room) for site moderators, and automatically add those users to the chat, to the exclusion of all other users.
Eventually I would also like to be able to map my site's groups functionality to MUC's in ejabberd also.
The external authentication API for ejabberd doesn't seem to provide for fine-grained access control, basically only allowing you to query whether a user is registered and whether a username / password combination successfully authenticates a user.
The only reference I've seen to acl's for MUC's is here:
http://www.ejabberd.im/aclpopulate
But that seems to require setting privileges through the webadmin interface.
Is there no way to do this automatically from external auth?
To answer my own question, it doesn't seem possible to do what I need by using external auth.
I ended up integrating ejabberd commands into the user / group lifecycle of my web app, which was quicker than I had anticipated, and has the added bonus of being a zillion times faster than using external auth (I use ejabberd's internal user database, using ejabberdctl to create users, update passwords, add and remove from shared rosters and create muc's).
To help with that process I created a PHP wrapper for ejabberdctl which is freely available on github:
https://github.com/tomlancaster/Ejabberd-Wrapper-PHP
Please feel free to use and abuse it as you wish.
If you have your own authentication module, in that case you can redirect the authentication process of ejabberd. In ejabberd_auth.erl file redirect authentication by modifying check_password_with_authmodule/3 and check_password_with_authmodule/5 two function. From your authentication module return back the term as these two functions return.
If you authentication module is in deferent machine, make a socket connection to communicate with your authentication module and get the result and give the result back to check_password_with_authmodul function.
After this changes rebuild ejabberd and start.