Single Sign On - 2.0 Web Service Membership Provider

No problem.

Well at its core, the primary objective of this project is to provide a web service interface to the 2.0 membership provider model. This allows other custom applications to authenticate using the same user base without having duplicate authentication systems for each application. So in the end you could potentially have n applications using one custom authentication system. The functions in the client library allow this to happen.

The release package contains four main projects: a server site, two test clients, and a client library. All you need to do to make another client application work is reference the SingleSignOn library and setup your config file to use the custom classes for its membership provider. The library will do all the rest.

Of course you also need to have the main website hosted as well. Like you said, it does use the basic built-in SqlMembership provider, but it also exposes the functions in that provider over web services, which then are consumed by the client library.

Does this make sense? This entire package is intended to be a starter kit for anything you want to do. You can change any of the code you want and make it fit for your specific situation.

Beyond this, when you start adding users and roles, you can easily use the built-in membership provider security to restrict access to components. In web, it's extremely easy using the authorization element in the web.config. You just setup your custom role with users assigned and then give that role access to the web application. i.e. (<allow roles="TestUsers"/>) In a windows application, it's a little more manual, but you still have the same access to System.Web.Security.Membership.Provider functions just as if you were right on the web server.

As far as the aspnet_application table is concerned. I'm honestly not sure what it's used for. I simply just passed through functionality using the membership provider interface. So in the end it's still using the SqlMembershipProvider, but I don't know in that context how it uses that table.

Did I answer your question?

Thanks,
Nathan

1) Yeah, the intended use is basically to setup Roles (user groups) to access applications and manually handle your authorization in the application. You could use System.Web.Security.Roles.Provider class to perform operations like IsUserInRole(username,rolename) to validate that a user belongs to a proper role for your application. In Windows applications, you'll manually have to perform these checks. Your roles could look something like "AccountingApp1Users" or "AccountingApp1Admins." At login in the client application AccountingApp1, you would make sure that the user is a member of the users role after they successfully authenticate username and password.
For more information on Role-Based Security goto MSDN at: http://msdn2.microsoft.com/en-us/library/52kd59t0.aspx

2) I have never personally tested this solution with 900+ users. But I'd be more than happy to hear feedback from you or anyone else that has seen how it performs in that environment. Also, let me know of any issues that may have come up when doing that. My strongest argument would only be that the built-in SqlMembership provider is essentially being used for this solution with web services in the middle. So as far as the actual traffic on the website directly, I'm sure that wouldn't be a problem. The component to really test is the web services and client authentication. Since it is a web based solution I'm sure 900+ requests wouldn't be that challenging of a prospect, but like I said, it is untested. There will likely be a bit more lag than your typical enterprise windows network with that many users.

Notes:
If you're using it in an enterprise environment, I would seriously consider looking at WCF or WSE and adapting these web services over to that architecture. The reason being, WCF Supports a much more robust security model and allows for authenticated web service consumers, encrypted handlers, digital signatures, policies, etc. I've also heard that performance is considerably better with some of the enhancements they've made like using direct TCP services instead of SOAP over HTTP, etc.
For more info on WCF see: http://msdn2.microsoft.com/en-us/library/ms735119.aspx

The security model in this solution is geared more for shared hosting trust limitations. The client key files are simply XML files that contain a unicode string used to validate access when invoking functions in the web services. Every function on the web service contains a parameter for the key and it then validates the key before it continues. This way someone on the web wouldn't be able to just reset a users' password or get a users' information simply by consuming the web services or browsing to the asmx and passing in parameters manually.

If you wanted to use this solution in its current form for your environment, I would recommend making a couple enhancements: To make this solution more secure for an environment like yours, host the webservices using SSL (which does not require code change) to allow transport security. Then modify the code to encrypt/decrypt the key file residing on the client machines. (You would have to change the read/write functions in the SingleSignOn library to perform the encryption/decryption operations). This way users wouldn't be able to "see" the key just by opening it with notepad, and the transport encryption (SSL) would encrypt the communication between your client applications and the web services so they couldn't get the key by sniffing network traffic.

If you're concerned about traffic, then just beefing up the web hosting is always an option. There's a huge amount of flexibility that comes with web applications. You can cluster servers, beef up machine hardware, etc to allow more simultaneous processing.

There's a lot you can do. I hope this helps!
-Nathan