- Security, A Primary Role of B2B Web Sites
- Mechanisms for Controlling Access to Data and Applications
- Implementing SQL-Based Authentication and Authorization
- Summary
This chapter is from the book
This chapter is from the book
This chapter is from the book
2.2 Mechanisms for Controlling Access to Data and Applications
The whole process of providing the right information to the right people begins with two basic concepts: authentication and authorization.
2.2.1 Authentication
Authentication is the process of identifying a user who is requesting access to an information system. Authentication is typically performed by taking the user through a login procedure of some sort. This user is called the principal. During the login process, principals present evidence of their identity so the system can be satisfied that they are who they claim to be. The proof of identity that a principal provides at login time is known as credentials. For example, a principal could offer his or her knowledge of a user ID and a password or something like an access card or a digital certificate as proof of identity. They might also use a physical feature or a biometric such as a scan of their fingerprint, retina, face, or voice. If a principal offers the correct credentials, the authentication process assumes that the principal is who he or she claims to be.
It is important to remember that if a thief steals someone's credentials, the thief can then impersonate the victim. Because the authentication process can't tell that an imposter is presenting someone else's credentials, it might be impossible to discover that something is amiss until long after the thief has gained access to the system in the victim's name and has done whatever damage he or she intended to do. Therefore, in order for the authorization process to keep out unauthorized persons, users of information systems must judiciously guard their credentials.
2.2.2 Authorization
Authorization is the process of deciding which resources a principal is permitted to access. In B2B applications, different principals will have different degrees of access.
The degrees of access in B2B applications, however are typically not limited to a single dimension.
The typical B2B application requires a matrix of authorization levels. Authorization must be granted based on multiple criteria, such as the following:
- Identity
- Employer
- Role
- Company type
The owners of the application must create a list of attributes that are relevant to their business and their B2B application. Based on my experience with B2B applications, the list of attributes should be kept to five or six at the most for performance and maintenance reasons and should include the attributes of identity, employer, and role.
Attributes such as these must be mapped and correlated to the way that the data is classified inside an organization. In other words, management has to decide which companies, users, and roles can have what type of access to which data inside the organization.
In order to put these decisions about data access and security into practice in B2B applications, the authentication and authorization mechanisms must be implemented using existing Internet-based technologies.
2.2.3 Options for Implementing Authentication and Authorization
Existing Web- and server-based technologies currently offer three techniques for implementing authentication and authorization: network operating system, third-party, and application-specific.
Network Operating System
Modern network operating systems typically offer some type of user authentication and authorization mechanism. Using a network operating system for authentication and authorization in B2B applications typically means representing the users of your B2B application in the user account management function of the server's network operating system (NOS). This user account management function might be a local user account database that is built into the NOS, or it might be an LDAP server, such as Microsoft Active Directory.
With this technique, you manage the users of your B2B application in the NOS user account database as if they were inside-the-enterprise users. However, this leads to a bit of a mismatch. Many, perhaps most, of the users of B2B applications are actually outside-the-enterprise users.
Keep in mind that many B2B users are actually not employees of the company that owns the B2B app. These users access the company's internal information systems only through the B2B Web site from outside the walls of the enterprise. You must also remember that your NOS user account management function was designed for managing employees of the company who are inside the walls of the enterprise, usually on a local area network.
An internal NOS user account database is not the right tool for managing external B2B application users. This mismatch between the tool and the job is manifest in two ways in B2B implementations.
The first mismatch is that you end up mixing internal and external users in the NOS user account database, which may make the maintenance process of the user database cumbersome. Having a large number of external, B2B app users in the NOS user account database could bog down the database and make it difficult to manage the enterprise's internal users in the same database. In addition, there is no tight coupling of the B2B application with the B2B user account management function. The user account management would happen with an administration tool that is provided by the NOS and that is separate from the rest of the B2B application.
Second, and more important, the granularity of the authorization mechanisms that NOS user account databases provide is typically not right for B2B applications. User account databases often provide a grouping function of some sort for users where the administrator can create groups or roles and then specify which users belong to these groups or roles. However, as explained earlier, a grouping mechanism like this is insufficient for B2B-type authorization, which needs to use attributes such as identity, employer, and role at a minimum In addition, most B2B applications need to keep a variety of application-specific user information. Many NOS user account databases have a limited ability to do this.
Active Directory provides some additional capabilities in that it enables users to be arranged in a hierarchy and enables additional attributes to be assigned to each user. However, Microsoft Active Directory has the following restrictions:
There may be performance limitations when querying for users based on their attributes instead of their place in the hierarchy.
There may be performance limitations when updating application-specific user information.
There may be insufficient support for transactional updates of user information.
Of course, you will need to test the performance of Active Directory yourself for use in your own B2B applications. Depending on the requirements of your application, the performance of Active Directory may be adequate.
Limited support for transactional updates of user information could be a significant problem for B2B applications, depending on what user information is kept in Active Directory and how often and in what way it must be updated.
Even in B2B applications that use Active Directory, there is often a need to keep user-specific information in a relational database. In those applications, Active Directory can play a role in providing a single sign-on capability for users inside the enterprise. In applications that require authenticating the inside-the-enterprise users, the developer of the B2B application often has to write some code that handles the integration of B2B user information that is in the database with the information that is in Active Directory.
The other authorization mechanism provided by NOS is Access Control Lists (ACLs), which enable administrators to assign a list of authorized users and groups to each resource. As is the case with NOS user account databases and Active Directory, the granularity of the authorization is not quite right for use with B2B apps. In the case of ACLs, they are too granular. You end up having to assign an ACL to each resource and then having to keep ACLs updated as users, groups, and resources change over time. This becomes a prohibitively large maintenance task. The bottom line is that your NOS often may not provide the authentication and authorization capability that your B2B applications require.
Third-Party
Another approach is to rely on a third party to provide authentication and authorization services, several of which are available on the Web. For example, Microsoft "HailStorm," which is based on the Microsoft Passport authentication system, is one service Web application developers can use to authenticate and authorize users.
As of this writing, "HailStorm" is not yet in operation, and other services appear to provide authentication but little that could be used for authorization in B2B applications, so it is difficult to predict what implementation issues might arise when using "HailStorm" or other Web-based authentication and authorization services with B2B applications.
Application-Specific
Unfortunately, the NOS and/or Active Directory may not provide all of the authorization capabilities that your B2B applications need, and remote Web-based authentication and authorization are not a reality at this time. So, depending on the application requirements, your B2B applications will need their own authorization mechanisms.
Because typical B2B applications must keep a variety of application-specific user information, the app will usually use a customized database to hold that user information. In nearly all B2B applications, it makes sense to use this database for authentication and authorization of principals as well. Using an application-specific authentication and authorization process for B2B apps has the additional advantage of allowing other applications, not just users, to log in to the B2B application.
Security for Cross-Company Applications Chapter 6 introduces the tools for building applications that span company boundaries using XML Web services and BizTalk Server. XML Web services leverage the SOAP protocol. SOAP stands for Simple Object Access Protocol, and it is a proposed standard for linking applications over the Internet. Simply put, SOAP is a remote procedure call (RPC) mechanism that is implemented via HTTP and XML.
The SOAP specification doesn't say anything about security. In fact, no security is required for HTTP, XML, or SOAP. In the absence of standards for securing messages, it's possible that SOAP is going to open up a whole new avenue for security vulnerabilities.
However, with an application-specific authentication and authorization process, you can implement user ID and password parameters in each of the methods and use SSL to keep them secure while they are traveling between client and server.