I would like to use the AzMan RoleManager API in my existing webapplication. I'm already using the default ASP.NET membership provider which stores its users in the ASPNETDB database.
I quickly took a look at AzMan and administered my policy store using the supplied tool. However I was only able to add local pc users (Windows server 2003) to the store. Is there an easy way to hook up AzMan with the default ASP.NET membership provider?
AzMan is based on the Windows Authorization Manager component, which has its own schema and management. It does not integrate with the ASP.NET membership provider to use it as a policy store, nor from which to select membership. AzMan can manage membership of any user for which it can determine a Security Identifier (SID), which can include users in a domain or an ADAM store. I don't believe there are any SIDs used in the ASP.NET Membership provider, unless you happen to be using Active Directory Membership Provider (but you already said you're using the SQL Server Membership Provider).
Short answer: No, there's not an easy way when starting from the SQL Server Membership Provider.
Related
I am using VS 2013 Asp.net 4.5.1 and created an internal webforms app using the Individual User Accounts option for Authentication. I want to use LDAP to authenticate the users and use the SQL DB that was created for Individual User Accounts option to hold the users info and roles. We don’t have Active Directory Federation Services (AD FS) so I can’t use the On-Premise Authentication method.
The AD username will be stored in the SQL DB
How can I authenticate the users using LDAP and then use the AspNet.Identity.EntityFramework to get to the users info and roles from the SQL DB?
You can use this implementation like an example, it is a customer UserStore for RavenDB:
Customizing ASPNET Authentication for RavenDB
There's this series of videos explaining how to work with security in .NET (the second video explains how to do it).
Customizing ASPNET Authentication with Identity
Brock Allen discusses how to implement an "external login" in his comprehensive article on the new identity patterns using External Logins.
Active Directory Federation Services (ADFS) supports a lot of identity protocols including SSO. However, If it's just POWA (plain ol' windows authentication), IIS will support that out of the box. You would simply specify your Active Directory(AD) user/AD Group in your web.config Authentication node and leverage the Identity.Name field to look-up users' info in a lazy-load and / or request-cached fashion.
If 's claim's based authentication using ADFS, you can emulate how that works using the Identity and Access Tool and choosing the "Use Local STS" option.
Why not keep the profiles and roles in LDAP (ADLDS) as well? ADLDS does an excellent job of tracking multi-valued attributes which I find useful. The role (group membership) in ADLDS is reflexive (you can query the role for members or query a user for their membership in roles). ADLDS also insures the referential integrity - you cannot have a member in a role if the member doesn't exist. I think you are facing some severe referential integrity problems by having accounts and profiles in two separate stores or learn to love the distributed transaction coordinator.
I have multiple websites and a Windows app that share the same database. Is there a way that I can manage the database username and password across all web.configs and app.configs? I'd like to be able to change the username and password, and then have all websites and apps use the new name. Is there something that I can use that will automate this? I currently store the username and password in a connection string.
You may have to write some custom code in your Windows app to support it, but ASP.NET Membership will let you share usernames and passwords among multiple apps.
http://msdn.microsoft.com/en-us/library/yh26yfzy.aspx
ASP.NET membership supports facilities for:
Creating new users and passwords.
Storing membership information (user names, passwords, and supporting
data) in Microsoft SQL Server, Active Directory, or an alternative
data store.
Authenticating users who visit your site. You can authenticate users
programmatically, or you can use the ASP.NET login controls to create
a complete authentication system that requires little or no code.
Managing passwords, which includes creating, changing, and resetting
them . Depending on membership options you choose, the membership
system can also provide an automated password-reset system that takes
a user-supplied question and response.
Exposing a unique identification for authenticated users that you can
use in your own applications and that also integrates with the ASP.NET
personalization and role-management (authorization) systems.
Specifying a custom membership provider, which allows you to
substitute your own code to manage membership and maintain membership
data in a custom data store
Also, see this SO question for some additional info.
Keep the user name and password in the registry.
Build the connection string on the fly using a class
All web sites and Apps should have the same class
By the way, the registry is more secure than the web config.
I am designing ASP.NET website for Intranet users. At the end of Phase-I this will be available to Intranet users.
But after Phase-II, the same site needs to be opened to certain users that are outside this office.
Can I can use ASP.NET Membership provider?
Any other design recommendations?
I appreciate your input.
This is what I would do.
I would use ASP.net MembershipProvider and use SQL server to store it.
Create roles (internal user and external user)
I would use high encryption for passwords for all users
user roles to limit the information external users can see
Yes, you can use the ASP.Net membership provider to allow external users to register and login to the site. Using this would ensure that the passwords are hashed with a salt and encrypted, thus making the user data more secure. The ASP.Net membership provider has a huge API set which might be confusing for developers, among other things. There is a simplified membership provider which is available in the WebMatrix suite called SimpleMembershipProvider, which is available in the WebMatrix.WebData namespace. This gives just enough API needed to create, manage, authenticate and authorize external users.
It depends on what you mean by "outside this office". You can use the ASP.NET membership classes with any sort of provider that may suite your needs. Do you mean by intranet users, that you want the users to be able to sign in to your web site with their windows domain account?
Generally you can use the SqlMembershipProvider to authenticate users against a SQL Server dabase with a given set of tables using the ASP.NET login controls. If you want to use the login controls and but want users to be able to login using their windows account you can use the ActiveDirectoryMembershipProvider. If none of the above is suitable for you, there's always the option to implement a custom provider.
All our inhouse projects use Active Directory authentication and impersonation as this is the accepted security policy for the company.
I currently have a scenario where I need to store user profile information, and I would like to use the built-in Profile Providers which is standard in ASP.Net. I've previously used this happily with Forms Authentication, however I can't find any helpful information on how to implement this when using Windows Authentication.
Is there any way I can get just the Profile Provider working with Windows Authentication out of the box?
Will I be forced to create a custom profile provider?
The data will be stored in the database, not in Active Directory. However if the latter is possible some guidance would be appreciated.
Notes
I don't need to use the Role provider, this is handled by AD.
I am not sure if I need to implemented the AD Membership provider to get the Profile Provider to work.
you can just use the standard SqlProfileProvider. As username, use the Context.User.Identity.Name property. ASP.NET will create a user entry in it's standard tables himself to keep track of it. The role provider also works in combination with windows authentication. See this link for more information: http://weblogs.asp.net/scottgu/pages/Recipe_3A00_-Implementing-Role_2D00_Based-Security-with-ASP.NET-2.0-using-Windows-Authentication-and-SQL-Server.aspx
if you enable and configure the profile provider in the web.config, you can use it like this:
ProfileBase profile = ProfileBase.Create(Context.User.Identity.Name, true);
profile.SetPropertyValue("MyProfileProperty", propertyValue);
profile.Save();
Good luck!
I'm in the process up changing a single SQL DB website (ASP.NET/VB.NET) into a multitenant app, where each client has their own database.
In the old site, all the ASP roles, logins and providers pointed to the single database.
Now we have multiple databases, I'm wondering what would the best architecture/techniques to use. There is one database that configures the tenants, such as the company name, various settings (that would normally be in a web.config) and the connection string to their tenant database.
Should we have all the membership & role stuff in the single database that configures the tenants or do we have membership & roles in each individual tenants database? Option 2 seems tricky because I think ASP.NET only likes one set of RoleProviders defined in the web.config.
Has anyone tried this before or got any recommendations?
If you're using the ASP.Net Membership model with the built-in providers' then putting them into one DB is the easiest as you indicated.
One option, and I've not tried this, is to define in your web.config file a provider for each tenant. This would allow each tenant to have their own membership db, and allow you to avoid username collisions between the tenants (if this is a requirement).
You should be able to configure the the ASP.NET membership database connection string at runtime. This thread has a few options including a custom membership provider or changing the value early on in the request lifecycle via Global.asax.cs.