I am creating a single user CMS application and I want to keep authentication lightweight so I don't need a full blown authentication system.
My admin section will have custom admin pages that I will create to update the db, write content, and I will also maybe even use the admin gem for some things.
I just want to lock down these protected pages.
Any simple yet secure options out there?
You might like this clearance. It is a full-power authentication, yet still very lightweight.
Related
I am pretty new to RoR development and newer to LocomotiveCMS...that said, I am trying to build a relatively simple site with LocomotiveCMS. Ideally, I would like to restrict the entire site from anonymous users, and then extend the roles as read-only, contribute, admin, etc. I see that Locomotive uses devise for authentication for /admin. Is there a way to restrict access to only authenticated users?
The easiest way to do this would be to make every page unpublished. Users would then have to be logged into the CMS to be able to see any of the pages.
This PR adds switch in page settings for restriction of anonymous users.
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 an app that is mostly in rails but also uses nodejs for some realtime features, for example, chat. Users log in via Rails and get assigned a session, etc as usual. However, what's the best way to authenticate with nodejs as that same user? For example I would like to prevent users from impersonating one another but login is done on rails right now and messaging is done on nodejs. Rails and nodejs both have access to the same database.
I am using devise and socketio if that matters.
There's a number of ways implementation wise that you could tackle this. The one that jumps to mind is to share the session cookie that devise uses with nodejs via the database.
IIRC devise creates an encrypted session cookie during authentication; save this value temporarily to your database, and let nodejs pop it off the database for its authentication. There's likely some difficulty in accomplishing this (porting some of the devise encryption to nodejs, and the like) but if you're doing a rails/nodejs app, I'm pretty sure you're capable of handling it. :D
The benefit here is that a user can't get between the hand-off to accomplish impersonation.
You could always generate a one-time token for any user passed between rails and node. Much, much easier than re-implementing (and maintaining) the crypto strategy used by devise and rails.
That said, sharing sessions between servers creates a lot of extra work for you and effectively doubles your bug surface area (schema, validations, etc.)
Faye is an awesome project which handles this exact use case, so it's probably worth a look :) http://faye.jcoglan.com/
We're building a Rails 3 web application that will need to authorize and authenticate regular users who visit the site. Those same users may also use third-party applications to access the site via our API.
What approaches can we use to effectively and cleanly provide access to clients as well as users? What strategies have you used in your own Rails applications that also have RESTful APIs?
Ideally, we're after a solution which:
plays well with Devise and CanCan (which we already use for authn/authz)
plays well with Mongoid
doesn't pollute our controllers
is relatively simple to install and configure, if it's a gem or plugin
is easily testable, if it's a general strategy; or is already tested, if it's a gem or plugin
Since you're already using Devise, take a look at the token_authenticatable strategy (Add it to your user model and make sure the devise init reflects whatever you call the token param).
You'll want to add: "before_save :ensure_authentication_token" to your user model as well (assuming you don't want it to be single use).
Just provide your user's with their tokens on say their profile page or wherever. Call it an API token if you like.
Are they sufficient in terms of security for use in a public site? OR so I need to make modifications?
It really depends on what kind of site you're making, but I'd probably not deploy the AccountController as-is. It's sample code which demonstrates the mechanics of using the MembershipProvider.
For example, some things to consider:
You might include CAPTCHA with Registration
The default template doesn't actually protect anything with an [Authorize] attribute. If you require a login, you probably want to have controllers and actions which require authorization.
etc...
Always take responsibility for your own site's security. I would do a threat model and figure out just how secure your site needs to be. For example, some sites require two factor authentication with something like an RSA keyfob. That's not included with the default template. I'd argue most sites don't need that level. ;) Point is, it depends on your specific needs. Hope that helps!
Are you asking about the membership and role providers or the skeleton controller actions and view? The membership and role providers certainly support secure storage for passwords and allow you to secure your application adequately. I found them to be a little overkill for the kinds of things that I do so I opted to implement my own. As far as the controller actions, they are just skeletons and you should expect to modify them to fit your authentication scenarios. For one thing you may want to set things up to require secure connections when transmitting passwords. If you choose to redirect afterwards to a non-secure connection, you'll need to manually manipulate the redirect url since the default routing doesn't support (or at least didn't in MVC Beta) changing back from secure to non-secure protocols.
The bottom line is that you still need to make sure that you are handling the data securely whether you are using MVC or WebForms. The layout of the controllers and basic set up is an adequate start, but you need to make sure that it fits your security requirements.