We have a legacy system that uses a resource/action based authorization. Recently our company has decided to use a LDAP server as a repository for both Authentication and Authorization.
I haven't worked with LDAP servers before but as far as I have learned we can define our schema for different objects.So I have searched the Net for a simple example of implementation of a resource/action based authorization using LDAP and I haven't found anything (Everybody is talking about users,group and roles)
So two questions come to my mind :
Is it a good idea to use LDAP for a resource-action based authorization
(Since I could not find a good example of how to do that)
If yes, how can we implement it? (Any google result would help :) )
PS: Our application is written in C#. Are there any good open source LDAP client out there that we can use or we should go with .Net DirectoryServices ?
You can take a step back and look at the bigger access control / authorization use case. IF you want to do resource-action based authorization, you can roll out ABAC, the attribute-based access control model.
ABAC is an evolution of RBAC and identity-centric authorization. It was designed by NIST, the same organization that standardized RBAC.
With ABAC, your LDAP server becomes a source of attributes. An attribute is simply a key-value pair. The benefit if using ABAC in your case is that you do not need to extend or change your LDAP schema.
With ABAC, you achieve the following benefits:
you externalize the authorization logic to a central policy decision point
you express the authorization logic as policies instead of roles
the policies can use any attribute of the user, resource, action, and context
You can express the following scenarios in ABAC:
a user with the role==manager can do the action==edit on a document if the document.location==user.location
XACML, the eXtensible Access Control Markup Language implements ABAC. You can read more on XACML and ABAC here:
ABAC: NIST project page.
XACML introduction & architecture.
You will need to deploy an interceptor (policy enforcement point) in front of the applications you want to protect.
LDAP is very flexible and you can define whatever schema you want but it's not an obvious task.
I would say it's very suitable for your case but I know of no default schema for that. Googling a bit , I found this RFC which might give you a starting point. Would that match what you need?
Regarding .Net library: is it a "pure" LDAP server or an Active Directory server ?
It seems DirectoryServersupports both so I would stick with it. Note that for a pure LDAP server, you would have to connect using System.DirectoryServices.Protocols.LdapConnection.
SO entries like this one would probably be helpful too.
Hope this helps.
Related
I know this question as been asked countless times, but believe me I've searched Google for hours and got nothing. Whatever is out there, it's for MVC, which I'm not using.
My requirement is simple. I do not want to use the default authentication provided in asp.net. I would store the username/password/role in my custom SQL Server table. I'll provide 2 inputs for username/password and a button to validate. On validation, he is allowed access to the admin areas. This will only be used by admin guys at my subdomain "admin.*.com". They will use this page to add content to the website on daily basis.
How do I implement it. A tutorial link would suffice.
Is it safe for Production? I don't want some newbie hacker getting in to my site and mess it up. If not safe, what else option do I have.
Thanks,
Dev
As per our comments, given your reluctance to implement an ASP.Net Membership provider (and it is worth the time to investigate - you may not feel that it is right now, but it can be handy. I felt the same way at first, but the cost of maintaining your own code and infrastructure soon proves to be false economy) you have at least two other choices:
1) Straightforward Forms Authentication
Put all of your admin pages under a single folder, for example, /Admin, then use Forms Authentication to protect access to this folder. Only users defined in the database or Web.Config will have access to these pages. This is less flexible than ASP.Net membership, but may give you most of what you want. In terms of security, this will be as secure as your website is, is well tested, and is well documented.
2) Use Facebook OAuth
You mentioned that your use has access to Facebook. You could use Facebook to do the authentication for you. Although you wont be able to grab the username and password, you can get a token back, that you can then validate against a known permission set. This is a lot more work than 1) though and will tie you to potential future changes in the Facebook API. However, it also benefits from being well tested, and secure, but you have little to no control over the actual user information.
As an aside, please also consider being nicer to Google!
You can create your own custom membership provider which has the features you are looking for.asp.net membership provider
Its best to use the tried and tested method for security purposes. Remember you can customise any providers including role providers or even create your own unique providers.
Here is an example how to LDAP authentication using ASP.NET 1.1. The logic may still be applicable or can be adapted to later versions of ASP.NET, although I have not tested it.
Using the built-in membership providers, or implementing your own, is no guarantee that a hacker can't get access to your system. Things you'll have to consider:
encrypting data between client and server
don't store passwords in the database, not even encrypted. Hash each password its own salt, if you can.
enforce strong password entropy.
make sure session and authorization cookies are marked HttpOnly and Secure
for admin passwords, have a policy to change them frequently (like once a month)
provide means to notify administrators when someone signs in to their accounts
temporarily lock out ip address who exceeds number of requests per second and failed to authenticate
temporarily lock out users when they enter their password more then x (e.g. 10) number of times in an y number of minutes (e.g. 10).
These are just a handful of things to look for. You'll also have to concern yourself with session highjacking, javascript attacks and so forth.
Its not a trivial matter.
Writing a custom authentication handler is very dangerous. There are many ways to get it wrong and leave your website vulnerable to attack.
I also understand your complaint that Forms Authentication is extremely complicated. I was faced at a similar cross roads and decided to build my own authentication system called FSCAuth. It's BSD licensed. It's designed to be super simple and to allow for just about any database format you can image. All that must be done to set it up is implement a small 4 function interface into your database and populate a few configuration fields.
I've got two programs, a "login" program that uses the a foreign STS (Google, Facebook, etc.) to log the user in and returns the type of security access that user has. I then want to send that information off to a separate program that takes that security access and gives the user privileges based on that.
What is the best way to send that information across?
I've read some things about the Custom Authorization Manager Service, but I'm not sure if that is what I need here. Is it possible to just POST the security info across and the web.config turns that into a claim? Should I be making a new token and sending that?
I am hopelessly lost. If someone could provide a helpful tutorial somewhere on the web, that would be immensely appreciated (as my googling has only turned up long-winded articles that either do much more than I need or much less).
Specific code snippets would make my day.
Thanks!
EDIT: I am trying to avoid making the login system into an STS. But I am starting to feel I need to. Is there some halfway point between STS and relying party? Like a relying party that can generate its own claims?
You have several options:
The simplest one is the ClaimsAuthorizationManager, which might be what you're looking for. http://msdn.microsoft.com/en-us/library/ee748497.aspx The CAM is a step in the ASP.NET authentication pipeline that runs right after your application has validated the security token incoming from ACS. Here is where you define your custom authorization logic, and you can add additional claims to the IClaimsPrincipal that gets delivered to yor application. Instead of centralizing authorization logic in a service, you could for example implement your CAM in a library that's shared accross various relying party applications.
If your authorization rules are simple, i.e., you're not querying any external user attribute store, then one option would be to use ACS claims transformation rules to do this. Then your applications would consume the token issued by ACS directly. http://msdn.microsoft.com/en-us/library/gg185955.aspx
If however your architecture absolutely requires a separate login service that consumes tokens and populates new tokens with user attributes and such, then it will need to be an STS. Building your own STS can be tricky, but there are prefabricated STSes available to do this. If your applications live in an AD domain for example, ADFS 2.0 would be an ideal choice because of it's close integration with AD and ACS, and it's powerful claims transformation capabilities.
I've looked to many sources, and found many examples, but none really fit the situation that I hope to take a project to. I am writing a bunch of WCF services, some publicly accessible, others not (server to server), that will allow a fully flexible cloud app that ensures the ability to scale out the service as needed through Azure. I am unsure which way to go with message authentication, as I want to make sure a particular user logged in, can perform different tasks, and prevent others from running those tasks.
Most of what I have seen uses roles or ASP.NET membership. I have my own custom membership users will use to login with, and I don't rely on standard membership providers, or active directory. What is your recommendation? I thought about just creating a token that is created on successful login, that is stored within a cookie, added as a parameter passed into each method, but with some research, I think this might be able to be handled without modifying all my methods.
What are your thoughts?
You can easily implement authentication without needing to manually pass a token into all your functions by using UserNameAuthentication and writing a custom validator - there is a fairly straightforward tutorial here
If you use UserNameAuthentication, you will need to use SSL/HTTPS, which means you'll need to get a server certificate - this is a good idea anyway for most business applications.
At the server side you can get the identity of the current user:
IIdentity wic = OperationContext.Current.ServiceSecurityContext.PrimaryIdentity as IIdentity;
use basic authentication and have the webservice authenticate against your membership store.
Does anyone know if the provided SQL and Active Directory Membership Providers in ASP.NET 2.0+ are HIPAA compliant?
Clarification:
I understand that HIPAA mandates patient information be secured and that certain policies be put in place to secure access to that information. Can Microsoft's SQL and AD Membership Providers be used for handling the authentication of users accessing this information? I expect there to be some policies that need to be established like password length and complexity but is there anything inherit about the way they store information that would invalidate them for the purposes of authorization? Any gotchas or things to look out for?
It depends on what you want to do with them, but in short, yes. HIPAA is all about standards for securing your data; the standards aren't particularly harsh, so long as you have a way in place to provide for security. In that way, it's a lot like ISO 9001; so long as you define a security policy and stick with it, you're okay. The mentioned providers are effectively tools.
That said, you may need to do some additional things with your data to assure that it's only clearly accessible from your application; some level of pre-encryption would probably be appropriate. Just understand that it probably doesn't need to be HEAVY encryption; very light would do, so long as you're consistent with the application of it.
I sure hope it is;) We currently use the 2.0 Membership Provider with an ADAM LDAP at the health insurance company that I work for. HIPAA and PHI are the name of the game here and this set up went through our legal department.
I'd say that out of the box, it is not HIPAA compliant.
The way to find out would be to create a new Web Application, with just a default.aspx and maybe a login page. Then click the "ASP.NET Configuration" tool in the Solution Explorer toolbar to launch the configuration application (you can also do this from IIS if your site is hosted there). Set up the defaults, choosing to use the AspNetSqlProvider for all features.
This will create an ASPNETDB.MDF in your App_Data folder. Right-click it and choose "Open". This will open it in Server Explorer, where you can look at all the tables that were created.
You'll find that the password is stored hashed in the aspnet_Membership table, instead of as plain text. That's a good thing. However, the email address is also stored in the clear. If I remember my HIPAA training from four years ago, that's PII, and should at least pretend to be special. As it is, anyone with access to the database could find the email address of any member.
Edit based on update:
If you're only talking about using them for authentication and authorization, I'd say you're ok. You will need to ignore the email address.
I'm building a new ASP.NET MVC application (in C#) and one of the requirements is to create a new database of members. For this, we'd need roles to manage the different types of members and profiles to manage the additional metadata attached to each member. So far so good, just use the standard MembershipProvider, RoleProvider and ProfileProvider provided as part of the .NET Framework.
However, the catch is that I'd like to allow different authentication methods. I'd like Accounts and Login Credentials to have a one-to-many relationship (one account can have a number of login credentials attached). A user for example, might have both an OpenID and ActiveDirectory account attached to their account.
However, after experimenting with a few ways we opted for the MembershipProvider route (explained how it was achieved as an answer below).
My question is, how have people done this before and how would people suggest I approach it? It appears to be something that is achieved on quite a number of sites, yet a search on here doesn't return anything solid to play around with.
EDIT: After looking around for a good period of hours overnight and this morning - I'm still not convincinced that butchering a single MembershipProvider would have been the easiest option. Does having multiple MembershipProviders give the same effect?
BOUNTY EDIT: With no responses, I am assuming that there is no more optimal solution that the one I posted as an answer. Is this really the case? I'm offering a bounty to try and see if anyone has any further thoughts on this and whether there are better alternatives.
BOUNTY ACCEPT EDIT: I think that WIF is the answer as accepted below, for a .NET 4 release and maybe other versions as it probably works with 3.5. Other than that, maybe a butchered MembershipProvider or adapted one may still be relevant.
In my opinion, the "real way" of doing this is to use federation with WIF (Windows Identity Foundation, formerly Geneva framework).
The idea is that you separate authentication from authorization. The authentication is performed by a so-called STS (Security Token Service) and it manages all the possible login mechanism that you want to support. When a user has been authenticated the STS issues a token containing a set of claims and the user's identity.
This token is sent to the web site (called a relying party in this lingo), and the website determines which parts of the site the user has access to based on the claims in the token. WIF supplies both membership and role providers that extract information from token.
You can read about creating a claims aware website here.
One of the pros of this approach is the separation of concerns between authentication and authorization. You do not need any complex membership and roleproviders in your website. Furthermore the STS can be reused to authenticate users to other applications you might have without them having to register more than once (effectively achieving single sign-on)
The downside is that you will have to spend some time studying these concepts and coding your STS. Mind you, it is not hard to code an STS with WIF, but it is not a 100% trivial task either.
If I have managed to tickle your interest I would recommend that you start out by reading this whitepaper.
Kind regards,
Klaus
One idea we've followed is to create a custom Membership / Role / Profile provider. We customised the login / authentication methods significantly and have an additional table of logins. This table basically just contained:
LoginID (Auto-Incremental ID, PK)
UserID (FK)
LoginSystemID (FK)
...blah blah
Within the above, the LoginSystemID was a link to a foreign lookup table which helped the system to determine which authentication service to use (e.g. Standard, AD, OpenID, FacebookConnect - etc).
The problem we ran into was that the Username field in the MembershipProvider couldn't be empty and while in our schema everyone had a UserID (it was their account name), they didn't have a Username that was unique. We had to get around this by generating a GUID and using that. This of course is hidden from the user and a DisplayName attribute from our Users table can be displayed instead.
This was all done via FormsAuthenication (the AD checks were done via LDAP checks). However, an additional layer (a webform) was added with appropriate settings within IIS that provided a means for automatic WindowsAuthentication - we redirect to there in the instance that we feel the user is likely to be internal (based on IP address).
Use standard framework stuff. See http://blogs.teamb.com/craigstuntz/2009/09/09/38390/
You can have an unlimited number of authentication methods attached to one account, the magic is in the FormsAuthentication.SetAuthCookie(userName, createPersistentCookie); statement