I just implemented Windows Live ID SSO (single sign-on) enabled for our use case project - www.usefulcases.com
I would say that the framework itself is easy, though I ran into an issue due to a configuration issue on our part (not Microsoft fault)
The problem I had was that domain was configured to "foward" so the callback, which was made in HTTP Post, got translated to HTTP Get, loosing the "token" from the server during the course.
I could not get the "token" and had to ask Live ID forum for this *strange* behavior. I got a prompt response for troubleshooting... Of course, it was something we did wrong, so we fixed it.
If we didn't have the configuration problem then it would have been about 1 hour of work from nothing to a SSO. That's pretty good.
Here is the basic step (off my memory)
Go to https://msm.live.com/app/registration.aspx?wa=wsignin1.0 and enter data. Pretty easy stuff. One thing: you need to specify the URL of the callback page. If you use C# sample (see below), it is named webauth-handler.aspx, which you can rename to something else. It can be located anywhere but once you set it, you can't change the registration record (you basically need to re-register, which is easy so not huge deal).
Once the registration succeeds, you get an app ID value.
Download the C# sample at from http://www.microsoft.com/downloads/details.aspx?FamilyId=8BA187E5-3630-437D-AFDF-59AB699A483D&displaylang=en
The sample is a small web app.
Copy one .cs file in App_Code to your web site's App_Code. This is the library class. Also copy the entire Sample folder to your website. I put it under ~\FM\LiveID folder. FM stands for Federation Management. I intend to add YahooBBAuth, so created a subfolder called "LiveID".
Open the web.config in the folder you just copied.
You need to modify a couple of lines: one for app ID (you just got that) and a secrete (that you specified at registration)
That's it!
The default.aspx page comes with a iframe that shows the "login" link as well as a code to check for a cookie that would be created if SSO succeeds.
Login using the "login" link. You get the standard Windows Live ID login screen at Microsoft server.
When SSO succeeds, the default.aspx will show the "token" value. This value is constant and represents this particular user (or Live ID account, to be precise).
Now, I should try Yahoo! BBAuth (in fact, I've already obtained application ID. I will write about it later.)
Showing posts with label SSO. Show all posts
Showing posts with label SSO. Show all posts
12/18/07
Tips for buidling SaaS (Software as a Service)
After building a SaaS solution, I found out about few rules that I should follow when I am engaged with another SaaS.
This was the first mistake I made. I create a model website, I set up a framework to create a clone of the model for each customer organization, with some configuration changes applied to each clone (or instance). Actually, when I designed this, the company was going to sell the product as a premise-based software. So by nature, it had to use "cloning" model.
Then, the company changed the direction and it decided to go to "SaaS" model, but we never made architectural adjustment to the product. It remained premise-based, and deployed in SaaS way.
One problem with cloning model is lack of scalability: cloning requires resources as we add more and you will quickly run out of resources like CPU, memory, and network bandwidth. The other problem is maintainance. It is a nightmare for operation stuff to apply patches, for instance, because therea are so many instances to make modifictions to.
Cloning also prevents us from using any sort of load-balancing strategies, which hurts performance.
Another big mistake was to use "in-proc" session state. First, session state should be avoided if possible and use alternative techniques like cookies. If your system has to support session state , then use session state server or SQL database session state server from day 1.
This forces developers to make any object stored in the session state collection serializable. Making an object serializable is relatively easy step (just declared [Serializable()] attribute at type level) but it helps developer realize that session objects are serialized and deserialized and sent accross a wire to a persistent storage. It, usually, makes developers careful about exessive use of session state facility.
"in-proc" session state has serious scalability issues too. The state information is store in a process memory, so any subsequent request must be serviced by the same process, which creates process affinity. This means you won't be able to set up effective load-balancing scheme. It also hurts reliability: because session state is in memory and if process dies, all session state disappear.
It is tempting to build a separate administartion application in a form of WinForm or a separate ASP.NET application. In a way, it clearly draws a line between the product and a supporting system.
However, introducing additional application to the whole picture causes more administrative headaches: operations stuff need to learn about another application. You would also end up duplicating many logics. For example, you need a separate security scheme, need a duplicate business logic and data access layer hiting the same database. If assemblies are shared, then it is less problematic, but if you write a separte code to hit the same database, then that makes changing database more difficult because two clients need to be updated.
Instead of creating a separate application, create another set of Actors like Admin, Ops, and Support. And then build a role-based security around the system and scope the capabilities around roles. That way, wheather you are an admin or end-user, you are subject to the same security infrastructure, and you can easily move around capabilities among Actors.
One of the most complex sub-system is the security sub-system that authenticates users. Every SaaS application out there has to have one. It is the most time-consuming sub-system and it has almost zero value to your SaaS offering. So, why waste time and money on it.
You split Security into Authentication and Authorization. You use Single Sign-on (SSO) to solve the Authentication and you build your own Authorization infrastructure. Often Authorization involves business objects and there is no choice but implement it yourself. On the other hand, authentication is pure infrastructure feature. I would recommend using Windows Live ID, Yahoo! ID, OpenID, etc. You could also implement Federation protocols like WS-Federation and SAML 2.0.
The time it takes for you to figure out Windows Live ID and Yahoo! ID is much shorter than the time it takes for you to build login system (with remember password, change password, secret question/answer, and all these crap) and test it.
Build a single website for all customers
This was the first mistake I made. I create a model website, I set up a framework to create a clone of the model for each customer organization, with some configuration changes applied to each clone (or instance). Actually, when I designed this, the company was going to sell the product as a premise-based software. So by nature, it had to use "cloning" model.
Then, the company changed the direction and it decided to go to "SaaS" model, but we never made architectural adjustment to the product. It remained premise-based, and deployed in SaaS way.
One problem with cloning model is lack of scalability: cloning requires resources as we add more and you will quickly run out of resources like CPU, memory, and network bandwidth. The other problem is maintainance. It is a nightmare for operation stuff to apply patches, for instance, because therea are so many instances to make modifictions to.
Cloning also prevents us from using any sort of load-balancing strategies, which hurts performance.
Enable ASP.NET session state server from Day 1
Another big mistake was to use "in-proc" session state. First, session state should be avoided if possible and use alternative techniques like cookies. If your system has to support session state , then use session state server or SQL database session state server from day 1.
This forces developers to make any object stored in the session state collection serializable. Making an object serializable is relatively easy step (just declared [Serializable()] attribute at type level) but it helps developer realize that session objects are serialized and deserialized and sent accross a wire to a persistent storage. It, usually, makes developers careful about exessive use of session state facility.
"in-proc" session state has serious scalability issues too. The state information is store in a process memory, so any subsequent request must be serviced by the same process, which creates process affinity. This means you won't be able to set up effective load-balancing scheme. It also hurts reliability: because session state is in memory and if process dies, all session state disappear.
Don't build separate Admin application
It is tempting to build a separate administartion application in a form of WinForm or a separate ASP.NET application. In a way, it clearly draws a line between the product and a supporting system.
However, introducing additional application to the whole picture causes more administrative headaches: operations stuff need to learn about another application. You would also end up duplicating many logics. For example, you need a separate security scheme, need a duplicate business logic and data access layer hiting the same database. If assemblies are shared, then it is less problematic, but if you write a separte code to hit the same database, then that makes changing database more difficult because two clients need to be updated.
Instead of creating a separate application, create another set of Actors like Admin, Ops, and Support. And then build a role-based security around the system and scope the capabilities around roles. That way, wheather you are an admin or end-user, you are subject to the same security infrastructure, and you can easily move around capabilities among Actors.
Use Single Sign-On instead of your own Identity server
One of the most complex sub-system is the security sub-system that authenticates users. Every SaaS application out there has to have one. It is the most time-consuming sub-system and it has almost zero value to your SaaS offering. So, why waste time and money on it.
You split Security into Authentication and Authorization. You use Single Sign-on (SSO) to solve the Authentication and you build your own Authorization infrastructure. Often Authorization involves business objects and there is no choice but implement it yourself. On the other hand, authentication is pure infrastructure feature. I would recommend using Windows Live ID, Yahoo! ID, OpenID, etc. You could also implement Federation protocols like WS-Federation and SAML 2.0.
The time it takes for you to figure out Windows Live ID and Yahoo! ID is much shorter than the time it takes for you to build login system (with remember password, change password, secret question/answer, and all these crap) and test it.
Subscribe to:
Posts (Atom)
