During this step the Role: Security Architect is responsible for the capture of the high-level security requirements for a project and the key architectural elements of that project. These requirements are captured in the Artifact: Software Architecture Document and Artifact: Supplementary Specifications and where these requirements significantly constrain the architecture of the solution then they should also be included in the Artifact: Reference Architecture. The role of the security architect is to elicit these complex requirements from the stakeholders in the project and capture them in easy to understand statements (intents).

The reason for the emphasis on intent at this stage is that in many cases when asked about security in a requirements gathering session (see Guideline: Requirements Workshop) most stakeholders will respond that "of course, everything must be secure", well does that mean that everything is encrypted, audited, and so on to which the reply is "oh yes, please". At this point the security architect explains the implications of such a decision, the cost, the complexity, and the group starts to have a meaningful discussion about which patterns are relevant to which elements in the architecture. It is these patterns that express the intent of the system with regard to security, whereas the design level patterns express the mechanisms for fulfilling the intent and finally implementation patterns express the technology used to fulfill the intent.

The high-level security patterns identified in this task are as follows. Elements of the System Architecture affected by security requirements (security affects both software and hardware elements) may now be associated with one or more of these patterns (preferrably documented in the Artifact: Software Architecture Document) such that they may be refined during design time activities.

Identity & Authentication

An end user has possession of an identifier (username) and/or a set of identifiers (titles, roles, alias) and proofs (password), which it keeps somewhere perhaps on a client system like a laptop or PDA. To authenticate, the user presents the identifier and proof to an application when prompted to identify itself to the application. If the application validates the identifier and proof, the user has successfully "authenticated" and the identity is now an "authenticated identity". When an application implements business logic and enforces its own security policies it needs to keep its data/metadata in an identity data/metadata repository (file system, database, etc). With the advent of the web, the end user no longer solely has application client code on its own system but often accesses applications through a browser, and the network locates the application through a URI (universal resource identifier) supplied by the end user.

Single Sign-On

When a user has multiple applications with different identifiers and proofs, it sometimes becomes difficult to manage the identity data and metadata to make the appropriate decisions. Single Sign-On (SSO) is a term applied to various techniques (human and automated) to reduce this complexity.

Solutions for SSO can be client based or server/service based and they can be tightly coupled or loosely coupled to the applications. Web based SSO refers to browser based solutions and typically include cookies. In tightly-coupled client-based SSO, the responsibility is on the user to register and synchronize multiple id/passwords which are maintained in multiple application repositories. Some SSO relies on "identity mapping" others provide "identity propagation" or "identity assertions". New initiatives in Federated SSO allow a user to register with a third party Identity Service Provider who then manages the user information thus providing a loosely-coupled alternative. In enterprises, a backend SSO can include the enterprise acting as the ISP. Backend SSO includes a common repository for all applications, and each application/server is reconfigured to not use a local repository. Backend SSO can also maintain multiple repositories for user information and utilize a management process to force the synchronization of the identity data in multiple repositories. When multiple identities are involved there are often requirements to isolate applications into realms, which often correlate to administrative domains.

Digital Identities

As people and businesses have become more dependent on computer technology, there has been a proliferation of identity related information created. With the awareness of identity theft, governments are legislating requirements for businesses on the protection of the identity information for which they are a custodian.

Digital Identity Solutions - There are two major strategies for managing Digital Identities. One is "user centric", and relies on a user actively participating in identity protection, by "registering" with third party providers and then granting permission to access their identity data & metadata to providers that they trust. The Liberty Alliance is a consortium that has been leading this strategy, but there is also an open source effort underway with the Higgins initiative in partnership within The Apache Foundation.

The second is a business centered model in which a business provides identity management services to its customers, partners and employees. The underlying technology is the same for each approach, but the governance and responsibility for providing digital identity management is different. Businesses deal with different volumes of information than individuals and therefore have different scaling requirements. Businesses also need to have their own systems for managing user access based on business roles and changing business conditions (i.e., you are always "My Self", but you may not always work for company xyz.)

Authorization

As people and businesses have become more dependent on computer technology, rules about who can access what resource have become codified. When designing applications, the decision of who can access what information, might depend on business context information or it may be externalized to the application and handled by a separate set of middleware. Most products and computer systems have implemented a set of "access control" mechanisms, but each one usually keeps its own mapping of authorized usernames to resource name and these are called "access control lists".

Message Protection

There are two basic types of protection; integrity protection (proof that the message has not been changed while in transit) and confidentiality ( application of cryptography to ensure that only authorized recipients can see the message). When messages are sent over a protocol each message can be digitally signed or encrypted or the network protocol can sign/encrypt all traffic between the two entry points. When the protocol provides the protection, it is often said to be "point to point" (i.e. network endpoint to network endpoint).