I have an application that is used by both internal employees and outside clients. I would like internal users to be authenticated against Active Directory, while clients use the Universal Providers membership provider.
I'm vaguely familiar with how to set up multiple membership providers, but what I'm not sure of is the best way to determine which provider to authenticate a user against. Is this a common scenario and if so, is there a standard approach to handling it?
I did something similar. However we used "Forms Authentication". In the Login.aspx.cs we first try to authenticate against Active Directory and if that fails then we go against a SQL database. It was much simpler in my eyes to do it this way.
Related
I have a legacy, monster software that is built around SQL membership. It isn't the most elegant code and sometimes the code goes directly into the database to pull users or roles out.
I need to migrate this to Active Directory. I'm thinking of authenticating against Active Directory, then saving the user on-demand into SQL. That way, the rest of the code works when trying to work with users, roles, etc against SQL. I would also have to plug the places where users are created and deleted.
Is it possible to authenticate against Active Directory via form authentication, but use SQL membership for the rest?
I'm sure what you ask is possible, but you may want to consider authenticating against ADFS instead of directly against Active Directory.
ADFS issues security tokens you can use to make authorization decisions. You can have it issue role claims into the token based on look-ups in a SQL attribute store. If your application is using things like IPrincipal.IsInRole to determine permissions, it should not have to change much.
Moving your application to token based authentication will make it easier to make your application internet ready (ADFS proxy) or trust issuers from other authentication domains (federation).
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.
I just inherited a project for a small company. This is a completely internal web application and the current model for authentication and roleManager is based on their domain policies. Well, I work from home and little experience with windows authentication, and I definitely am not part of a domain.
So, in order to "fake" the same sort of setup that they have, is it a good idea to setup ASP.Net Membership in SQL Server? And I think that you can setup roles in there, too, which I could use to create a one-one mapping of roles in SQL to what they have on their network (there are 5 or so, that's all), correct?
Then, when I push changes to their system, I would just overwrite my web.config with one specific to them, that basically sets Membership auth and rolemanager to user their network setting instead of my SQL ones. This would let me test locally but they could keep their domain driven security model.
Am I crazy, and these 2 things just aren't analogous?
The two things aren't the same so you're not going to be able to work on it as you are thinking. The membership provider would always require a login process and other user management, and the code to check the role membership and user account details would be completely different.
My suggestion would be to see if they have VPN access to their LAN and get them to set you up an account on the domain.
I have an existing production application that uses vanilla ASP.Net Membership for authentication.
However, I'd like to provide other means of authentication as well as the current ASP.net membership system, such as Facebook.
The Windows Azure Access Control Service makes this extremely easy and straight forward. Provided, that is, you're starting a new web application from scratch.
So, in this case, how do I
Integrate the Access Control Service authentication into my app without affecting the current login system and its users?
Migrate users over or Link logins? ( not sure if this is even possible)
Thanks all
Roberto
You need to create a custom identity provider based on your membership database. See this article on custom WS-Federation Identity Providers that can be integrated to access control: http://msdn.microsoft.com/en-us/library/windowsazure/gg185933.aspx
Also see this article on one that was written on top of the membership database: http://blogs.msdn.com/b/vbertocci/archive/2009/04/23/enhance-your-asp-net-membership-based-website-by-adding-identity-provider-capabilities.aspx
Approach of creating an identity provider (IP) based on your ASP.NET membership database which Paul Tyng suggested is valid.
However, it means that if you just create an IP you'll allow log in to all people who are authorised with other IPs (e.g. Google or Facebook). I'm guessing it's not what you want - you'd still want people to first register (either plainly with username-password or with their external identity). If that's the case then your task is the following:
Add a data store for users' external identities which is related to your existing Users table.
Modify the ACS login handling within your application to check that the identity returned from ACS actually exists in your members database.
Perform member log in (instead of federated log in) if you found the returned identity in your db.
Add external identity tie in during the registration process so your Identities table can be actually populated.
(optional) Re-use the bulk of the #4 mechanism to provide an ability to attach external identity to existing user accounts (i.e. I already have a normal membership with you and now want to add an ability to log in with Google as well, for example).
There is no one single tutorial/walk-through to achieve this (or I have not found one) so I had to pull bits from a variety of sources to make it work. Please let me know in the comment if I understood your requirement correctly and I'll add a guide on how to set this up. Cheers!
Might be a bit late, but check out the following blog posts by fellow Windows Azure MVP - Dominik Bayer:
Mixing Forms and Token Authentication in a single ASP.NET Application
Mixing Forms and Token Authentication in a single ASP.NET Application (the Details)
Replacing ASP.NET Forms Authentication with WIF Session Authentication (for the better)
Invaluable readings which will help you in any way!
Do we need to use out proc sessions while implementing SSO?What will be the limitation of inproc?
which is best way of implementing SSO across domain?
The use of inproc session vs. persisted session has little to do with SSO. The main limitation of inproc sessions is that it won't work in a loadbalanced setup, but again, it has little to do with SSO. The easiest way to implement SSO is to use the Windows Identity Foundation (WIF), which is part of .net framework 4.0 (there is also a version that works with .net 3.5).
Basically you just implement a passive STS. There are several walkthroughs out there.
If both of these applications are using forms authentication then the solution is easy. All you have to do is configure the machineKey on both applications to be identical and set the domain on the forms cookie to be .exampledomain.com for both web.configs.
If you're using a custom authentication scheme built around session variables, you might want to consider configuring both servers to point to the same SQL Session State database. If you go this route, you can modify the GetTempAppID to always return 1 and configure the machineKey on both applications to be identical. Just another suggestion from your friendly sheero. HOI!
inproc sessions will be an issue if your application is running behind the load balancers, so you might want to think about SQL server based sessions, plus you also need to think about if you really need a usual SSO that just keeps you automatically logged in, like if your user has different rights/permission set on different sites then you might want to add some custom code in your SSO login piece, as you have mentioned that you are using ASP.Net 2.0 so i am assuming you might be using the .Net role based profiles for group security and permissions, so you also might want to check if you get your self in a scenario where your logged-in user has different permission set in your different sites. So for me its not just SSO its custom login code for a specific requirement you might want to look into.