Road Map for an Application/Software Security Architect (Part 5)

Without a Digital Identity, how would you expect to do any authentication? And with an incomplete Digital Identity, how would you expect to get the authorization done correctly? Without the proper data model and the expectation that it would have the correct data (besides being in the right place at the right time), securing a system is impossible, although having the information, it is the easiest question to answer.
In my last post, I examined the purpose of a Digital Identity and why it is not appropriate when thinking through the architecture of a solution to make this another after-thought of the system architecture. Worse than not having the information (a security risk), is that the information is inaccurate, both in reliability and conflicting (a business risk). So let me lay out some rules and guidelines, and a couple of general questions you might ask as part of the logical design.
But before getting started, a good data model of the infrastructure that is used for authentication and authorization is required. This is part of the overall security framework, which has an “as is” as well as a “to be” component. In this case (and the subject of a framework and road map is, obviously, going to be mentioned again), we look at where the data is that identifies the person (of computer) and all the information that is stored about the person. (or computer), best described in as a data model with a component model. Let’s deal with each.
The data model defines all of the attributes that would be part of the digital identity. But who’s digital identity? An enterprise (or organization) has a number of different types of users, known as constituents. Typical constituents would be employees (temporary, permanent, vendor-access), customers, and business partner representatives; basically anyone that may have access to your systems and services. ,Each set of constituents would have a basic set of attributes, like user name and password, and a distinctive set of attributes, such as employee number or customer number. Everything about that constituent is termed as its digital identity. In general, the more you “know” about the constituent, the better your challenge for authentication and determination of authorization.
The component model defines where the attributes necessary for the digital identity reside. Just because they are defined as necessary does not mean that they are available. The objective of this document is to determine where the information resides. It is the responsibility of this document to determine also the reliability of the information and whether the place where the attribute resides is the most accurate. What you need is the source of the attribute data, or, if not available the most reliable copy of the information. Duplicate information about an attribute is a warning sign that information being provided for digital identity may not be the most reliable (more when we look at identity management). [How many applications are using the wrong copy of the attribute, the one that is, perhaps, not updated as often?]
While the two models are logical, the assumption is that the digital identity of any of the constituents may not be physically on a single database or LDAP-accessed directory. An Active Directory may have sufficient data about credentials, but it will be less reliable for a person’s job function, which could determine the role. The component model will likely include indications of multiple stores, and data models will indicate relationships between the multiple stores (and be not always consistent, either). It will also indicate the “owner” of the information (attribute as well as database)
With this, now comes the discussion with the application (or service) designer to review the data necessary for the authentication and authorization (credential checking) access sequence. The objective of this discussion is to review the following (partial) list of items:

1. Define the constituents that will have access, and the types of access that is necessary as well as the business reason for the access.
2. What is the method of authentication and is this sufficient for the data that is being exposed as part of the business reason for the access.
3. What are the business rules for the types of access, defining what would be the answer to the question of “do you have authorization for access (coarse grained)?”
4. What are the business rules for the types of access, defining what would be the answer to the question of “do you have authorization for the type of access (fine grained)?”
5. What other information is required from the digital identity to support the process of access into the system or service? Hint. Application designers like to take information with them for use in the session handling (stored in a session table), usually to be part of the cookie, such as name, address, or subscriber number, that is more reliably obtained during the access control session from the digital identity.

Contributed By:

Steve Primost CISSP, CISM
Information/Application Security Architect