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.

Trust is a key aspect in any security solution. The need for security is based on the premise that two parties share some level of trust and that level can be on a scale from "completely trusted" (therefore no need for security) or "completely untrusted" (where paranoia rules).

1. No trust ... aka blind trust: The provider may be providing a public service and has no need to trust the invoking system. The invoking system may send an identity with no proof and expect the provider to assume the identity when processing the request. There may be no measures taken to prevent impersonation attacks.
2. Network configuration based trust: There is no software configuration that provides trust. The network is configured, possibly through division into firewalled subnets, in such a way to restrict the number of machines that could transmit a message to the provider. The degenerative case would see only the intended invoking system and provider system on the subnet. Sometimes VPN's are used to restrict the potential invoking systems.
3. Infrastructure based trust: The infrastructure (e.g. transport protocol ... possibly MA SSL, or SSL + BA) is configured to identify the invoking system in order to validate that it's a trusted system. There is nothing in the web services (SOAP) message other than the invoker identity that the provider should assume when processing the request.
4. Token based trust: Point to point token trust - There is a token in the message that asserts an invoker identity and which was provably created by a trusted invoking system (e.g. SAML, LTPA). Third party token trust - There is a token in the message that asserts an invoker identity and which was provably created by a trusted third party system KDC/STS (e.g. SAML, Kerberos).
5. Token context based trust: Signature that covers the token and message - There is a signature in the message created by a trusted invoking system that covers the message and the token asserting the invoker identity and which authenticates the invoking system. Two tokens in the message - There is a token in the message that authenticates the invoking system as a trusted system and another token that identifies the invoker. There needs to be some mechanism to bind the two tokens together and to the message, such as a signature.
6. The extreme end of "trust" is authentication. Any token that provides proof removes the need for an extra mechanism whose purpose it to establish trust.

Trust Zones

In large organizations it is often efficient to subdivide the enterprise into administrative regions and establish different trust zones. Between different zones there are various subtypes of trust relationships that can be established. These are examples of some of the ways two parties can establish a trust relationship when only one of the parties has a relationship with the end user.

• Direct Trust - Token Exchange: Trust Domain 1 authenticates the end user and Trust Domain 2 requires an identity or identifier (identity propagation). In some cases ( i.e. only personalization is required) authentication may not be needed.
• Direct Trust - Token Validation: Trust Domain 1 may create a new assertion (an identity assertion) offering its own proof that it has authenticated the identified user. Trust domain 2, evaluates that this assertion came from someone it trusts (Trust Domain 1) and uses it in place of authenticating the user itself
• Token Services and ISPs: Sometimes trust relationships are established between multiple parties and the authentication of the user is separated out into an independent service (identity service provider). These identity service providers have varying degrees of functionality. Some can look at the destination of the request and determine if the user has been authenticated, and know if the current token needs to be exchanged for a second token and can redirect this request to the appropriate parties.
• Indirect Trust: Sometimes parties do not have a direct trust relationship, but they do share a third party that they both trust to "broker" an exchange.
• Delegation: Combinations of direct and indirect trust relationships can be established

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).