The Security Model


Before we can discuss the WebSphere security model, we need to start by defining the key terms and security principles on which the model is based. We will then summarize the J2EE and Java security model followed by the full WebSphere security model – showing how this model builds on the J2EE security model.

Protection Domain

Protection domain represents the scope over which the security system will protect resources. This is both a topological statement (the set of resources that can be protected), and a policy enforcement statement (the set of resources that are affected by a given policy statement, and the extent to which those resources are in a position within the network in which those policies can be assured). It is common to talk about the protection domain in terms of a single application server process as this scope is fairly well defined, and the trusted-computing base for the application server is relatively easy to understand. However, this is just one sub-scope within the entire WebSphere-based network of application servers and client processes.

Principal

A principal is any entity in the environment that we want to associate with a verifiable identity. This is most often a person, but it can be other things as well. For example, you may want to give your server process an identity. The server process can then be authenticated to the system and will be allowed or disallowed to perform certain activities based on what that principal (the server process, in this case) has been authorized to do. All principals have a security account in the user registry that retains information about that principal – such as their identity, how they can be authenticated, what groups they belong in, and so on.

Encryption

Converting a piece of data between its clear-text form and an un-readable form (based on a key) is at the basis of the Java, J2EE, and WebSphere security model. Encryption sustains the premise that information can be obscured and cannot be converted back to a readable form without the correct key.

Encryption can be achieved with either symmetric-key algorithms (where the same key is used to encrypt and decrypt the data – also referred to as private-key encryption since the key must be kept private) or public-key algorithms (using two related keys – one for encrypting and the other for decrypting the data). The latter is particularly useful for exchanging information between two parties. The sender can encrypt with one key, and the receiver can decrypt with another key. One key is kept private and the other key can be made public, depending on the effect you're trying to achieve.

Authentication

Authentication is the process of establishing that a principal is who it claims to be. There are a variety of techniques for proving authenticity, but the most common form entails the principal supplying their user ID and password. The user ID establishes who they are claiming to be, and since only they should know their password, then supplying the password is taken as proof of who they are. It's not hard to imagine cases where other people (or processes) have obtained a principal's password. If they do, then they can easily masquerade as that principal – pretending to be that principal by supplying that principal's user ID and password. Thus password-based authentication is often considered to be a relatively weak form of authentication – only as strong as the password is hard to guess, and to the extent the principal has kept their password a secret.

Other forms of authentication, such as certificate-based authentication represent stronger forms of authentication as they require either possessing something physical (like the key to your house), some physical aspect of who you are (such as your finger print, voice, the blood-vessel pattern in your eye, or your signature), or a combination of things, in addition to knowledge of a secret.

Credential

Credential is used in a couple of ways. From an information perspective, your credentials are the attributes about who you are – your title, your degree, your passport, and so on, that give a proof of your knowledge or capabilities. In the information system, a credential is an object that represents the authenticity of a principal. A credential will contain zero or more authentication tokens indicating how the principal represented by the credential was proven to be authentic. Based on the form of the authentication token, you can deduce the relative strength of that authentication. The credential will also contain a set of privilege attributes that could be deduced from the form of authentication performed and the security registry used to authenticate the principal.

Credential Mapping

Credential mapping represents a conversion of a credential representing a principal in one realm to another credential representing that same principal in another realm. This is needed whenever you initiate work that will cross runtime infrastructures associated with different user registries. For example, if your application invokes a servlet and a set of EJBs running in WebSphere against an LDAP-based registry associated with the WebSphere installation, and then calls out to a BAPI transaction running on SAP (which uses its own user registry for defining principals), you will need to perform a credential mapping if you are to continue to be associated with the request as it traverses into SAP. You will want to do this if you want to execute under your own authorization permissions in SAP.

Under other circumstances, the access to BAPI transactions could be performed under the authority of the WebSphere application server, in which case the application server must be authorized in SAP to execute on your behalf (that is, to perform the work that you need done by SAP).

Authorization

Authorization is the process of controlling access to resources based on policies that establish who can do what actions on what resources. Different policies have different levels of granularity. Some policies, for example, may allow that any authenticated user can access any resource in the system. This would be considered a very coarse-grained policy.

More common policies state that principals are allowed to perform certain roles – that is, they are allowed to invoke those operations on object types that are associated with that role. These are considered fine-grained authorization policies – being specified down to the granularity of individual methods on a class of objects. Even finer than that are policies that are based on the relationship between the principal and the state of the objects they are attempting to access. These are also sometimes referred to as instance-based authorization policies as they're dependent on the state of the object instance.

As a general rule, the more fine-grained the policy, the more impact there is on the runtime code-path to the resource. In other words, fine-grained authorization policies generally will have more performance impact than coarse-grained policies. Conversely, coarse-grained policies provide less control over who can do what in the system.

Privilege Attribute

Privilege Attribute states things about the principal; such as what user groups they belong to, and what enterprise role they perform, and so on. This information may be used in authorization policies. For example, an authorization policy may grant a particular group access to a resource. If you are a member of that group, then you will by extension, be granted to that same resource. Ideally, group membership is based on something meaningful in your organization – like the department you are in, or your job title or function, and so on. Being a member of that group essentially claims that you have the privileges of that group.

Message Protection

Message protection describes how messages are protected when communicated between different processes and computers in the network. Different degrees of protection can be associated with a message – ranging from none, to integrity protection, to field or message confidentiality. Integrity protection is basically a mechanism to ensure that nobody in the network can change the contents of a message (although it doesn't necessarily prevent anyone in the network from reading the information in the message). Confidentiality is used to prevent anyone from reading the information in the message. Field-level confidentiality says that only individual fields are hidden from anyone in the network, whereas message-level confidentiality says that the message cannot be read by anyone in the network.

Obviously, in either case, you typically want the end-user – the principal to whom you are sending the message – to be able to read the message you send to them. The message protection system is responsible for protecting the message in such a way that only the intended end user can retrieve it.

Digital Signatures

Digital signatures are a message encoding technique using public-key encryption to form a strong bond between a message and the person that created it (or signed it). Digital signatures are used just like your written signature on a document – they can be taken as some level of endorsement of the document you've signed.

Non-Repudiation

Non-Repudiation is an additional level of security that can be used to prevent an end user from denying that they sent a message, or from denying that they received a message. Most non-repudiation systems involve signing the message with a digital signature, and a heavy dose of auditing. The signature is used to prove that you, and only you, could have sent the document (you cannot repudiate having sent it). Likewise, signing the acknowledgement message can be used to prove that you received it. The audit is used to record these actions, when they occurred, the strength of the encryption mechanisms used in the transaction, characteristics of the key production and management system, and so on – things that will have to be revealed as part of any dispute of repudiation.

Security Architecture

Let us now discuss the J2EE security model. This forms the foundation of the WebSphere security model that we will discuss later in this chapter. The following diagram depicts the elements of the security architecture:

click to expand

In the diagram above, the Security Association Interceptor protects communication between EJB clients and servers. The WebSphere interceptor supports protection in accordance with either the IBM (also referred to as the Secure Association Service) protocol, or the CORBA standard CSIv2 (Common Secure Interoperation, version 2) protocol over IIOP. This protocol ensures both secure association establishment, and message protection in accordance with the protection policies of the server.

The HTTP Security Collaborator protects HTTP communication. This supports standard HTTP protection mechanisms, including basic-auth, client-certificate, and forms-based authentication and message protection, in accordance with the protection policies of the target application.

The Trust Association Interceptor can be used to integrate the security mechanisms of third-party proxy servers. Tivoli's WebSEAL (part of the Tivoli Access Manager product) can be integrated with WebSphere through the trust association interceptor.

Next, the Java 2 Security Manager forms the foundation of the security system for the WebSphere application server. It provides code-source protection based on J2EE permission settings, and provides the basic security objects used in the system. Java 2 Security Manager permissions can be controlled either with the configuration mechanisms in WebSphere, or through Tivoli Access Manager.

The Java Authentication and Authorization Service (JAAS) is a layer on top of the Java 2 Security Manager to provide authentication services. These are used by the runtime to validate in-bound secure associations, and to establish out-bound secure associations. WebSphere augments the JAAS framework with its own login modules that delegate authentication decisions and the formation of LTPA and SWAM credential tokens to the WebSphere security server. The security server is integral to the WebSphere runtime and will be hosted in the application server, the node agent, or the cell manager depending on your configuration (the placement of this server is automatic).

The web and EJB containers are responsible for enforcing authorization and delegation policies, and performing role-reference mapping in accordance with the deployment policies of your application. The containers will delegate authorization decisions to the permission mechanisms in JAAS, which in turn get authorization policies either from the deployed application or a separate authorization repository.

The application along with its deployment policies forms the top-most layer of the security architecture. Finally, users (principals) and groups are defined in the user registry. The authentication information for principals is also maintained in the user registry and is used to make authentication decisions by the security server. WebSphere bundles the IBM Directory Server that you can use as the user registry, but you can opt to use any of a number of other registries – including a variety of LDAP servers, the native user registry of your local operating system, or your own custom registry. You will manage users and groups (the creation and deletion of these) through the ID Management tools that are provided by your user registry – for example, the native user and group management tools of your operating system if you use a local OS registry.

We will discuss the elements of the security system in more detail throughout this chapter.




Professional IBM WebSphere 5. 0 Applicationa Server
Professional IBM WebSphere 5. 0 Applicationa Server
ISBN: N/A
EAN: N/A
Year: 2001
Pages: 135

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net