Tuesday, September 26, 2006
Dan Ciruli has a good post on software as a service (SAAS) in the trenches here. In it he talks about a number of concerns that CIO's raise. One of the concerns revolves around data security. Companies want to be able to own the only copy of their data (not in some vendor's database halfway across the country) and they want to have the ability to apply different levels of access to the data based on how the data is used. Having been involved in more than one SaaS projects, the discussions I've heard the same things over and over from clients: Where will my data live, and how will you secure it? In general, discussions usually go like this:
Project Lead: Your users can login to your own custom-branded site and use the system.
Customer: How do I limit access to the site?
Project Lead: We have an admin screen that you can use to setup users.
Customer: What if I want this integrated with my ActiveDirectory security? When a user quits, I want one way to turn off access to the application. Can I do that?
Project Lead: No, you'd have to use the admin tool to remove the user. We're working on the ActiveDirctory integration for the next release
Customer: Well, OK, so how do I prevent users outside of the company from going to the site and hacking into it?
Project Lead: We have a very secure data center.
Customer: What about data, where will it live?
Project Lead: At our data center.
Customer: So, if something happens to the data center, I won't have access to the data? What if your site is down, and what if this is our accounting system, then we can't use the system.
Project Lead: Well, yes, but we do have a service level agreement that we'd have to adhere to or your subscription will get reduced. Also, our data center also has a service level agreement.
Customer: I honestly don't really care about the reduced subscription rate, but at your prices this application needs to be bulletproof. I need access to this data 24-7. So, do you have a backup plan for my data?
Project Lead: of course.
Customer: OK, let me think about it. I'll get back to you.
The project lead goes back to the team and tells them to firgure out a way to integrate their application with ActiveDirectory. The project lead also has some conversations with their hosting site. The customer discusses purchasing the service with the executive management team. The customer calls the project lead up:
Customer: Well, I talked with the management here, and they had some concerns over data access.
Project Lead: Our security policies are very comprehensive, your data will be secure.
Customer: I can't guarantee that my data will be secure, unless I own the data, behind my firewall.
Project Lead: Well I see your point, but you won't be able to get the advantages of automatic feature upgrades and centralized administration if we are unable to access the application behind your firewall.
Customer: Access and control of our data is our biggest concern, the other 'features' are not essential. Also, how do we get the data out of your system? Can we export the data into Excel?
Project Lead: Well, we don't have an easy way of doing this, I suppose you could export most of the data to Excel, but some of the data will take a little more work to get to it.
Project Lead: What databases do you have available for use?
Customer: Oracle. Some MySQL.
Project Lead: Well, currently our application only works with SQL Server, and we'd need to make some modifications to give you the ability to host the application behind your firewall.
Customer: We like the features of the application, but having a system that we can host ourselves is a requirement. Let me know when you have an application that will integrate with our security model and our network architecture.
Project Lead: OK, I'll see what I can do...
I've seen most conversations with customers turn out like this, especially when you are trying to sell to the first handful of customers. As the number of customers increases, there's usually trust in numbers, so it becomes less of a concern if a potential client can see that other clients trust you with their data. I'm sure the first few customers that SalesForce tried to get had issues around data access and security. If you are unable to convince them to trust you with their data, you have two choices:
Project Lead: Your users can login to your own custom-branded site and use the system.
Customer: How do I limit access to the site?
Project Lead: We have an admin screen that you can use to setup users.
Customer: What if I want this integrated with my ActiveDirectory security? When a user quits, I want one way to turn off access to the application. Can I do that?
Project Lead: No, you'd have to use the admin tool to remove the user. We're working on the ActiveDirctory integration for the next release
Customer: Well, OK, so how do I prevent users outside of the company from going to the site and hacking into it?
Project Lead: We have a very secure data center.
Customer: What about data, where will it live?
Project Lead: At our data center.
Customer: So, if something happens to the data center, I won't have access to the data? What if your site is down, and what if this is our accounting system, then we can't use the system.
Project Lead: Well, yes, but we do have a service level agreement that we'd have to adhere to or your subscription will get reduced. Also, our data center also has a service level agreement.
Customer: I honestly don't really care about the reduced subscription rate, but at your prices this application needs to be bulletproof. I need access to this data 24-7. So, do you have a backup plan for my data?
Project Lead: of course.
Customer: OK, let me think about it. I'll get back to you.
The project lead goes back to the team and tells them to firgure out a way to integrate their application with ActiveDirectory. The project lead also has some conversations with their hosting site. The customer discusses purchasing the service with the executive management team. The customer calls the project lead up:
Customer: Well, I talked with the management here, and they had some concerns over data access.
Project Lead: Our security policies are very comprehensive, your data will be secure.
Customer: I can't guarantee that my data will be secure, unless I own the data, behind my firewall.
Project Lead: Well I see your point, but you won't be able to get the advantages of automatic feature upgrades and centralized administration if we are unable to access the application behind your firewall.
Customer: Access and control of our data is our biggest concern, the other 'features' are not essential. Also, how do we get the data out of your system? Can we export the data into Excel?
Project Lead: Well, we don't have an easy way of doing this, I suppose you could export most of the data to Excel, but some of the data will take a little more work to get to it.
Project Lead: What databases do you have available for use?
Customer: Oracle. Some MySQL.
Project Lead: Well, currently our application only works with SQL Server, and we'd need to make some modifications to give you the ability to host the application behind your firewall.
Customer: We like the features of the application, but having a system that we can host ourselves is a requirement. Let me know when you have an application that will integrate with our security model and our network architecture.
Project Lead: OK, I'll see what I can do...
I've seen most conversations with customers turn out like this, especially when you are trying to sell to the first handful of customers. As the number of customers increases, there's usually trust in numbers, so it becomes less of a concern if a potential client can see that other clients trust you with their data. I'm sure the first few customers that SalesForce tried to get had issues around data access and security. If you are unable to convince them to trust you with their data, you have two choices:
- Convert your application into a hosted solution that the customer can install on their own servers and manage. Don't forget to think about how they will install and upgrade the application. And security. And data migration from legacy systems. And browser support. And rollback strategies.
- Try and convince some other large enterprise customer that trusting you with their data is the only way to go.
Tuesday, September 19, 2006
I was unable to find the documentation or a code sample that described how to configure the connectionString node in the dataConfiguration.config for the Data Access Application Block 2.0 (DAAB). I searched the web and Google groups and each example shown used Integrated Security. So, I had to take a look at the DAAB source code to figure out which parameters I needed to configure.
In Data Access Application Block 2.0 To specify the connection strings for both integrated security and SQL security, you configure the dataConfiguration.config file:
This will configure the DAAB to use SQL Security:
This will configure the DAAB to use Integrated Security:
In Data Access Application Block 2.0 To specify the connection strings for both integrated security and SQL security, you configure the dataConfiguration.config file:
This will configure the DAAB to use SQL Security:
<connectionStrings>
<connectionString name="SQLSecConnStr">
<parameters>
<parameter name="database" value="Database" isSensitive="false" />
<parameter name="uid" value="Test" isSensitive="true" />
<parameter name="pwd" value="Test" isSensitive="true" />
<parameter name="server" value="WWW.XX.YY.ZZ\SQLInstance" isSensitive="false" />
</parameters>
</connectionString>
</connectionStrings>
This will configure the DAAB to use Integrated Security:
<connectionStrings>
<connectionString name="IntSecConnStr">
<parameters>
<parameter name="database" value="Database" isSensitive="false" />
<parameter name="Integrated Security" value="true" />
<parameter name="server" value="WWW.XX.YY.ZZ\SQLInstance" isSensitive="false" />
</parameters>
</connectionString>
</connectionStrings>
