I am working with an asp.net application in .net 4.0. I have configured it to use windows integrated authentication.
What I want it to do is use the user groups on my pc/server as if they were roles. I can't find documentation or mention of it anywhere from my google results.
The reason this is required is because we have a COTS product which does this and we want to reuse the groups as roles.
Could I get an example or a pointer to some documentation so I can figure out how to do it?
The end result here was that we communicated with our Sever Services team who were more than happy to help us use Active Directory to come up with a Corporate solution instead of using individual server user stores. This is a much better solution as the groups are reusable and integrate with other applications too.
The lesson here is that engagement with IT services with a business case is always worth the effort.
Related
I'm trying to find a solution to handle authentication on my new application, and I like the approach of IdentityServer3. I would like to hope my requirements are met by IdentityServer3 and it's just my lack of understanding due to my newness with the technology.
My requirements are as follows, and in order of desired execution:
1) If a user requesting authentication is a local (domain) user, they should be authenticated automatically using Active Directory.
2) If a user requesting authentication is not found in Active Directory, they should be authenticated against our own User table.
3) If a user requesting authentication is in neither Authority, we may choose to grant access via Google or Facebook credentials, but that's not a Phase I requirement.
I currently have a working proof of concept using IdentityServer3 as a standalone security server pulling records from the InMemoryUsers, InMemoryClients and InMemoryScopes, and I'm fairly sure I'll be able to expand on those concepts for pulling from our own database.
This problem comes when I try to use Active Directory as the first checkpoint.
I've looked at a couple of resources in an effort to accomplish the Active Directory, but I'm getting all tripped up as I'm not seeing any concise demo that shows the AD piece of the puzzle.
TJ Robinson has a Gist of an ActiveDirectoryUserService that implements IUserService, and that looks to be the most promising, but because of my n00b status, I can't seem to figure out how to roll it into the scheme.
I would really appreciate any suggestions, and, perhaps, links to examples of how to do AD authentication first with a fallback to local authentication.
Thanks in advance,
Ric
In regard to your first requirement...
I believe you should examine the Windows Authentication Service. This is essentially a mini security-token-service that can work as an external identity provider to IdentityServer to provide Windows Authentication (over the WS-Fed protocol).
If you follow that link to the GitHub page, you will find two links to samples that can you get started with this component. One sample has both Identity Server and the Windows Authentication Service hosted separately and the other sample has them hosted together.
A separate option could be to use ADFS (if you have one) as an external identity provider.
Those samples include a custom user service (ExternalRegistrationUserService) that shows those windows users being mapped to an in-memory collection of users (in Identity Server). Your requirements will obviously demand a different implementation of that user service, but I hope this might help get your started with the Windows Auth part.
When I went through this exercise recently, I found a lot of good information in the closed IdentityServer3 issues (for windows auth). Lots of good info on Stack Overflow as well; good luck!
I am making an intranet mvc app for in-house use. Only other guy in the shop is the server tech. I am told we have a domain controller and we use AD, every user is in groups. I'm pretty sure we use windows authentication (based on we have to log in to our workstation.
I'm not sure if I should be using the UserPrincipal in Directory Services, or the Current.User stuff in HTTPContext, or something else, for authenticating users. Only people in certain AD groups should be able to open the app.
Obviously I know nothing about app security stuff. I plan to hit the books, as soon as I figure out which "technology" I should be using. I also need to check users against specific groups. I almost had that figured out, but I am getting false when I know it should be true.
if (HttpContext.Current.User.IsInRole("MyADGroup"))
{
IsAdmin = true; //keeps returning false.
}
So what should I be looking into?
You can use this example to help you get started with Active Directory Roles.
Since the application is in-house, you don't want to stray far from Windows Authentication, but I do recommend looking into LDAP.
Connecting to an LDAP Server
Good luck!
You can hook up the internal application to use users and groups from AD by using the ActiveDirectoryMembershipProvider. Then simply authenticate against the provider instances (Membership.ValidateUser). This allows you to use AD as a backing store but isolates your application from an explicit dependence on it. This will also populate the UserPrincipal on the HttpContext.
I would recommend using this with a standard login form, though IIS will allow you to configure Windows authentication for the entire site. Using a standard login form along with AD-backed authentication allows you to maintain the decoupling and also expose some parts of the site as public pages by allowing anonymous access. This can be useful for things like application help and FAQs which might be useful to someone trying to log on but either disallowed by permission or using the incorrect credentials. Provides a better user experience as well.
The project I'm working on is a set of tools for users to manage their own accounts. For example, generic users will be able to access and update their Drive or calendars, and for administrators they can additionally get lists of their users and groups and manage those.
My concern is the API limits. At this point in time the project's client ID and secret are hard-coded because I want users to just be able to download and run the tools (which is working great until someone queries all users and uses up half of the daily limit for one of the APIs). I realize I can request more API calls, but I'm not sure that's the best solution.
In order to have each user on their own API limits, will I need to have each person using it set up a new Google Code project with its own set of limits? Or is there a way to allow the same project to have limits based on domain? I'm not sure what best practice is.
Edit: I should mention I'm authenticating via OAuth2.0 using 2-legged authentication, as my understanding was that was the best way to do it for administrators and users... should I be using 3-legged instead?
This is (probably) not an answer, but ...
A good question is precisely what is an "app". In this answer What is the limit on Google Drive API usage?, Nivco from Google says "Currently for the Drive API it reads "Courtesy limit: 10,000,000 queries/day". It's a per app quota"
and on the API Console, your project can consist of many "apps", each with its own client ID.
So, either (a) the term "app", being ill-defined, is being used incorrectly, or (b) you can achieve what you are looking for by creating multiple apps within your project.
Sadly, I suspect it's (a), but might be worth confirming.
Is it possible to use this Role Provider AspNetWindowsTokenRoleProvider with ASP.NET FORMS Authentication (via this MembershipProvider System.Web.Security.ActiveDirectoryMembershipProvider)?
It seems to only work with <authentication mode="Windows">, is it possible to use it with FORMS?
background -- The objective here is to provide an ASP.NET Forms UX while using Active Directory as the back-end authentication system. If there is another, easy way to do this using built-in technologies, that's great and I'd like to hear about that as well.
update
I should say that I have the authentication working, what I'm struggling with is adding a level of granular control (such as Roles).
Currently, I have to setup my Active Directory Connection to point to a specific OU in my domain, which limits access to only users physically in that OU -- what I'd like is to point my Active Directory connection to my entire domain, and restrict access based on Group Membership (aka Roles) this works if I use Windows Authentication -- but I'd like to have the best of both worlds, is this possible without writing my own RoleProvider?
As others have mentioned, you cannot use the ActiveDirectoryMembershipProvider with the AspNetWindowsTokenRoleProvider. If you want to use the ADMP with Forms Authentication, you have a few choices:
Use the AuthorizationManager aka AzMan. - AzMan is built into Windows 2003+ and can interact with Active Directory groups. In addition, there is an AuthorizationStoreRoleProvider built into .NET 2.0+ that you can use to interact with it. AzMan works on Task, Operations and Roles wherein presumably your application would be coded to act on specific Tasks which could then be grouped into Operations and you can then create Roles which have authority to perform various Operations. There is a management application that gets installed when you install AzMan that you can use to manage Tasks, Operations and Roles. However, there are some downsides to AzMan. First, the AuthorizationStoreRoleProvider does not recognize Tasks. Rather, it loads the Roles list with a list of Operations. Thus, unless you create a custom version of the provider, your applications would need to seek Operation names instead of Task names. Second, it can be a bear to work with in that interaction, at the lowest level, is still via COM. Unless you want your administrators having to use the AzMan tool, you'll need to write your own pages to manage Operations, Roles and membership in roles.
Use the SqlRoleProvider and map roles to usernames. The advantage of this solution is that it is very simple to implement. You can pretty much use it out of the box since the RoleProvider operates on username and not UserId. In your code you would simply check for IsInRole to determine if the given user had been dropped into a role that your code recognizes. The significant downside is that it is geared on usernames only and not AD groups and thus there is no means for an admin to use the AD tools to manage users. Instead, you have to write a management console to manage role membership. In addition, changing a username at the AD level would require an update to your application's list of known usernames.
Write (or locate) a custom AD RoleProvider that honors AD groups. Writing a custom role provider is not for the faint of heart but doing so lets administrators manage role membership using their existing AD tools.
Implement your own ADAuthorizeAttribute by inheriting from AuthorizeAttribute and overriding AuthorizeCore. It's a lot easier than implementing your own role provider or installing and configuring AzMan.
See my example here:
ASP .NET MVC Forms authorization with Active Directory groups.
Yes, you are right; it will work only with windows forms authentication. You can confirm it here:
http://msdn.microsoft.com/en-us/library/system.web.security.windowstokenroleprovider.aspx
Just a suggestion. Try AuthorizationStoreRoleProvider with AzMan (Authorization Manager). It worked for me (ages ago, so I don't remember much).
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.