EASI (End to End Enterprise Application Security Integration) Framework

The EASI framework specifies the interactions among the security services and application components that use those security services. By using common interfaces, it’s possible to add new security technology solutions without making big changes to the existing framework. In this way, the EASI framework supports “plug-ins” for new security technologies.

Applications

The security framework provides enterprise security services for presentation components, business logic components, and the back office. The framework supports security mechanisms that enforce security on behalf of security aware and security unaware applications.

Security Aware Application

The security aware application uses the security Application Program Interfaces (APIs) to access and validate the security policies that apply to it. Security aware applications may directly access security functions that enable the applications to perform additional security checks and fully exploit the capabilities of the security infrastructure.

Security Unaware Application

The security unaware application does not explicitly call security services, but it is still secured by the supporting environment (an Enterprise Java Bean [EJB] container). Security is typically enforced for security unaware applications by using interceptors, which transparently call the underlying security APIs on behalf of the application. This approach reduces the burden on application developers to develop security modules within the application and lessens the chance of security flaws being introduced.

Other applications, called security self-reliant applications, do not use any of the security services provided by the framework. A security self-reliant application may not use the security services because it has no security relevant functionality and, thus, does not need to be secured, or because it uses separate independent security functions that are not part of the defined EASI security framework.

Application Programming Interfaces (APIs)

The framework security APIs are called explicitly by security aware applications and implicitly by security unaware applications via interceptors. Security APIs provide interfaces for access to the framework security services. The framework supports standard, custom, and vendor security APIs.

Standard Security API

Support for APIs is based on open standards or industry de facto standards, such as XML (SAML), J2EE, .NET, and CORBA. These standards should be used whenever possible because they are likely to provide the most stability and the most flexibility across many different vendors’ products.

Custom Security API

Custom APIs may be implemented when an enterprise’s needs cannot be met by existing standard APIs. Custom APIs are required especially when an enterprise uses a security service that is tailored to its business, for example, a custom rule-based entitlements engine developed internally by an investment bank.

Vendor Security API

As a last resort, vendor-specific proprietary APIs may be used where open standards have not yet been defined. You should avoid using proprietary security APIs in applications if at all possible. Proprietary APIs make it very difficult for the developer or administrator to switch security products. Although vendors may think this is a great idea, security technology is changing much too rapidly to be confined to any one product. As an alternative, you should wrap a vendor’s proprietary API with a standard or custom API.

Core Security Services

The next layer of the security framework provides core security services enabling end-to-end application security across multitier applications. Each of the security services defines a wrapper that sits between the security APIs and the security products. The security services wrappers serve to isolate applications from underlying security products. By creating a new wrapper, it is straightforward to switch security products without affecting application code, if the need arises. The key security services are authentication, authorization, cryptography, accountability, and security administration.

Authentication

Verifying that principals (human users, registered system entities, and components) are who they claim to be is what is known as authentication. The result of authentication is a set of credentials, which describe the attributes (identity, role, group, clearance) that may be associated with the authenticated principal.

Authorization

Granting of permission for principals to access resources is what is known as authorization. Data integrity and confidentiality access controls enforce restrictions of access to prevent unauthorized use. Data integrity controls ensure that only authorized principals may modify resources. Data confidentiality controls ensure that resource contents are disclosed only to authorized principals.

Cryptography

Cryptographic algorithms and protocols for protecting data and messages from disclosure and/or modification is what is known as cryptography. Encryption provides confidentiality by encoding data into an unintelligible form with a reversible algorithm that allows the holder of the encryption key(s) to decode the encrypted data. Digital signatures apply cryptography to ensure that data is authentic and has not been modified during storage or transmission.

Accountability

Ensuring that principals are accountable for their actions is what is known as accountability. A security audit provides a record of security-relevant events and permits monitoring of a principal’s actions in a system. Nonrepudiation provides irrefutable proof of data origin and/or receipt.

Security Administration

Security administration is the process of defining and maintaining the security policies embodied in user profiles, authentication, authorization, and accountability mechanisms. This also includes other data relevant to the security framework.

Framework Security Facilities

The framework provides general security facilities that support the core security services. The framework security facilities are the profile manager, security association, and proxy services.

Profile Manager

The profile manager provides a general facility for persistent storage of user and application profile data. It allows data to be accessed by other framework services.

Security Association

Security association handles the principal’s security credentials and controls how they propagate. During a communication between any two client and target application components, the security association establishes the trust in each party’s credentials, and creates the security context that will be used when protecting requests and responses in transit between client and target. The security association controls the use of delegation, which allows a delegated intermediate to use the credentials of an initiating principal so that the delegate may act on behalf of the initiating principal.

Security Proxy Services

Security proxy services provide interoperability between different security technology domains by acting as a server in the client’s technology domain. This also includes a client in the target’s domain.

Security Products

Implementation of the framework generally requires several security technology products that collectively comprise the enterprise security services. Example security products that are required include firewalls, Web authentication/authorization products, component authentication/authorization products, cryptographic products, and directory services.