The password vault has also assumed control over embedded local administrator accounts on servers and PC systems, service accounts, database access and application accounts that used to be embedded in systems. These accounts were typically never watched closely and could NOT have passwords changed in the past without breaking lots of systems. As we have moved these accounts and passwords into control by the tool, we rotate them regularly without issue. Lastly, we now have a disaster recovery copy of them via a replication of this, too. As a result, our DR/BC plans are tighter as well.
One portal, many client databases: A privacy challenge
Can you execute a web system as a portal when the authentication and data is setup as client-specific? That was the question faced by James Ashbaugh, a Senior .Net Architect with a Midwest-based business management consultancy. The company had several clients running the same system code, with data housed in separate physical boxes. But the clients were all competing organizations in the same industry, so data integrity was of utmost importance and Ashbaugh was concerned about how the system was configured.
Let me set the stage for you: - Around 500-1000 external users connecting via Citrix - MS Network - Windows 2003 Servers for Domain Controller, Web Servers, SQL Servers - SQL Server 2008
The web portal runs based on client, user roles and client DB data. Microsoft provides a rich, role-based model with ASP.Net, but that model is not designed to run under a portal structure. So, we married what Microsoft provided in ASP.Net security, Active Directory Accounts/Groups and SQL Security.
Now, here is the wrinkle: The company had multiple (competing) clients running the same system code, but data was housed in separate physical SQL boxes (with client-specific database names). So, everyone ran the same web application and middle tier, but at the DB level it was client specific (everyone was on the same DB model). Remember, our clients connected to our company via Citrix, so single sign-on was a requirement (even though Citrix handled the DMZ authentication, it did not handle the forms authentication with our web applications). It's important to understand that the clients are in the same industry, so data integrity is a must because of competitive advantage.
So, the challenge was how to authenticate, load, execute the web system as a portal when the authentication and data was setup as client specific?
This is how we managed it: In Citrix we shared Internet Explorer as an application (but restricted clients from external web navigation via IE security settings with a login script). We did not want a client using our servers a means to surf the Internet or generate attacks to competitors. The home page of IE was set to our web portal. Using delegation and impersonation we took the Citrix Authenticated user and passed the credentials to the loader code class of the portal. That class kicked off an authentication process to an "authenticate" SQL DB. In this DB we had all the client DBs and client users and roles mapped. Once the loader authenticated this was an active user in the system, the loader would get the appropriate DB connection information and then pass it along in the user's web session. Did we encrypt it? Yes, we found that cross-site scripting attacks could be used to capture session information of other users. Encrypting the connection information in session meant the hacker would need to be on the physical web server and get to the page file or memory block at exactly the time any decryption algorithm was executed. Since this is not very likely, we supported the client requirements of data security at the DB connection level. In the DB, all connection strings and setting are stored in an encrypted form using a client-specific private key (the encrypted data comes from the "authenticate" DB).
Join the CIO Australia group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.