Freelance Graphics - Security Introduction · Architecture -- Create a security framework /architecture for the enterprise. Deployment -- Install the security solutions (Technology,

IBM WebSphere Web Multi-Platform Configuration

Security Introduction

06/26/00 © Copyright 2000 IBM Corporation Security_Introduction.prz 1


Background of Security


The Basic "No Security" End-to-End Model

This is the customer. The client can be either a single userPC or a whole company. The devices will be specified when necessary.

This is the router to the Internet. This is typically provided by an ISP (Internet Service Provider). This model, however, can apply to a corporate Intranet. This router separates the internal network from the outside network.

This is the company's Web server. This provides the universal access to the company's business logic. This allows the browser access to the company's corporation. Above the Web server is the organization's company router/access device.

This is the business logic. These applications have access to the databases. These "applications" provide the company business rules.

This is the company's data. Ultimately this is the information the company wishes to share with the customer. This data can be centralized or distributed. For this example, the data is accessed through business logic.

I-RouterClient Apps Data

(Internet)

Router

Web


The Risks to the Basic Model

ImmaImma Crook Crook

Imma Crook (also known as The Snoop) is the fellow that makes a network administrator's life miserable. It is Imma that will steal, crack, hack, destroy, or deny service for fun, and or profit.

VulnerabilitiesSecurity Flaw in Systems

Attacks

Attacks

Attacks

Counter measures

Technical or procedural means of addressing vulnerabilitiesor thwarting specific attacks

Threats

Motivated Adversaries capableof mounting attacks

HackersDisgruntled EmployeesIndustrial SpiesTerroristsSpecial Interest GroupsJournalistReal SpiesCriminals (Organized or otherwise)

Means to exploit a vulnerability

(PEOPLE!!!)


What is Needed to Achieve Security

Confidentiality

Integrity

Accountability (non-repudiation)

Authenticity

Availability

Remember: Security is relative...

Access Control


It is best to consider security prior to setting up the system; however, in some cases, security can be added later without problems.

Types of Security

Authentication - Proves who you are

Authorization (Capacity) - What functions are you allowed to perform

Delegation - Forwards the credentials to the tasks that are activated after the initial request

Encryption - Provides a secure, encoded data channel

Firewall - A blockade between a secure internal network and an untrusted network such as the Internet


Identification/authentication: Are you who you say you are?

Resource control/confidentiality (Delegation): Do you have permission to view or modify the requested item?

Integrity: How to ensure that the correct items are available and that no user has changed them.

Where do I begin?

Assessment

Education

Deployment

Detection

Response

Assessment -- Examine of the current state of security preparedness and identify weaknesses.Education -- Learn those elements identified in Assessment stage.Policies -- Refine the Policies and Procedures Documents.Architecture -- Create a security framework /architecture for the enterprise.Deployment -- Install the security solutions (Technology, Policy, and Procedures).Detection -- Detect weaknesses before they can be exploited.Response -- Design an emergency plan that can be implemented immediately.

Policies

Architecture



Authentication


Authentication used in Network Security

Type 1: Client authentication with userid/password, no server certificate

no SSL

Type 2: Server Authentication through Server certificate, Client Authentication through userid/password

SSL V2/V3

Type 3: Server and Client Authentication through Certificate

SSL V3


Secure Sockets Layer (SSL) was originally created by Netscape. SSL is the industry standard for session encryption between clients and servers. SSL uses symmetric key encryption to encrypt the session between a server and client (user). The client and server negotiate this session key during an exchange of digital certificates. The key expires automatically after 24 hours, and a different key is created for each client and server connection. Consequently, even if unauthorized users intercept and decrypt a session key (which is unlikely), they cannot use it to eavesdrop on later sessions.

A digital certificate is a digital document that validates the identity of the certificate's owner, much as a passport does. A trusted party, called a Certificate Authority (CA) issues digital certificates to users and servers. The trust in the CA is the foundation of trust in the certificate as a valid credential. Use them to:

Establish identification - know whom the user is.Establish authentication - ensure that the user is who he says he is.Maintain integrity - determine whether the contents of the document have been altered by verifying the sender's digital "signature".Maintain non-repudiation - guarantee that a user cannot claim to have performed some action. For example, the user cannot dispute that he authorized an electronic purchase with a credit card.

A digital signature on an electronic document is equivalent to a personal signature on a written document. A digital signature provides proof of the document's origin. The certificate owner "signs" a document by using the private key that is associated with the certificate. The recipient of the document uses the corresponding public key to decrypt the signature, which verifies the sender as the same source.

Type 1: Client userid/password

Password transmitted in clear (lightly masked)Man-in-the-middle attackAuthentication stored at server

WebServer

WebBrowser

3. Request Web Page

5. userid = peterpassword = pumpkin

4. 401

Admin

2. Tell useruserid = peter

password = pumpkin

1. Register useruserid = peter

password = pumpkin

AuthenticationDB

6. Check Password


WebSphere Basic Authentication

Type 2: Server Certificate, Client userid/password

Password transmitted over SSLMan-in-the-middle attack (can be detected)Authentication stored at serverWeb Browser authenticates server certificate

WebServer

WebBrowser

3. Request Web Page

5. userid = peterpassword = pumpkin

4. 401 andserver certificate

Admin

2. Tell useruserid = peter

password = pumpkin

1. Register useruserid = peter

password = pumpkin

AuthenticationDB

6. Check Password


WebSphere Basic Authentication over SSL

Type 3: Server and Client Certificate

WebServer

WebBrowser

3. Request Web Page

5. Send client certificate

4. Received and validatedserver certificate and

certificate required error

Admin

2. Request and receive certificate

1. Request and receiveserver certificate

AuthenticationDB


WebSphere Certificate Authentication


LDAP


LDAP stands for Lightweight Directory Access Protocol.

Directory Access Protocol

In 1988, the Consultative Committee on International Telephony and Telegraphy (CCITT), created the X.500 standard. X.500 organizes directory entries in a hierarchical name space specifies that the communication between the directory client and the directory server uses the directory access protocol (DAP).

DAP requires the entire Open System Interconnection (OSI) protocol stack to operate.


LDAP

The University of Michigan and ISO Consortium developed LDAP.

LDAP is designed to run directly on the TCP/IP stack.

Like DAP, LDAP is an informational model and a protocol for querying and manipulating the model.

LDAP is a vendor independent open network protocol standard.


ISO is the acronym for the International Standards Organization.

TCP/IP is the acronym for Transmission Control Protocol/Internet Protocol.

Accessing LDAP

Since LDAP is a standard, a client to an LDAP server does not need to know how the server stores the information.

You can control who has authority to perform operations on the LDAP server by using access control lists (ACLs).

ACLs can be either inherited or explicit.


Inherited - Using one class as your base and then modifying or adding to it to create a new class.

Explicit - Protected single use of a class.

LDAP Directory Structure

c=UKc=US

"root"

o=IBM o=ciber o=Mayo

cn=Ron Ulmer

objectClass=country

objectClass=organization

objectClass=person

[email protected]=555-555-5555


LDAP is a directory service, not a database. Therefore, the information in an LDAP directory is usually descriptive, attribute-based information. LDAP users generally read the information in the directory much more than they change it.

Updates are usually all-or-nothing changes.

The LDAP directory service model is based on entries (which are also referred to as objects).

Each entry consists of one or more attributes, such as a name or address, and a type.

The types typically consist of mnemonic strings, such as cn for common name or mail for e-mail address.

Each directory entry also has a special attribute called objectClass. This attribute controls which attributes are required and allowed in each entry. This means that the values of the objectClass attribute determine the schema rules the entry must obey.


LTPA


LTPA

Lightweight Third-Party AuthenticationIBM Service running over LDAP, provides Single Signon and DelegationAuthentication information is carried in LTPA TokensFor interoperability with other products, a Single Signon Token that contains a userid and password can be issuedLDAP directory services required for the LTPA authentication mechanism


LTPA Tokens

Once a user is authenticated, the user receives an LTPA token.

Subsequent requests for authentication are handled by extracting the information from the LTPA token.

LTPA tokens have configurable time-out values.


Servers that need to validate the token decrypt the token by using the shared key and verify the signature by using the public key of the LTPA Server.

LTPA Token, ConcludedCookieName = "LtpaToken"CookieValue = Base64Encoded(LtpaToken)LtpaToken = Encrypt(AuthenticationToken, SharedKey) by using 3DESAuthenticationToken = UserData+"%"+TokenExpirationDate+"%"+

Base64Encoded(DigitalSignature)DigitalSignature = Sign (UserData, TokenExpirationDate) by using

PrivateKey-ltpa. (use RSA/SHA1)PrivateKey-ltpa = Private Key (corresponding to a Public Key that other

servers can access) that is used by LtpaServer to sign the authentication data; this private key should be accessible to the LtpaServer only.

SharedKey = A symmetric/shared 3DES key that is shared by LtpaServer and other servers for encrypting and

decrypting the token. UserData = Name value pairs separated by delimiter "$". (for

example, "u:"+userID)TokenExpirationDate = A number representing the time and date of the token

expiration.


TokenExpirationDate is the number of seconds to elapse since midnight (00:00:00), January 1, 1970).


Authorization


Authorization Policy

Authorization involves granting trusted Principals permission to perform actions on resources (that is, Web Pages, Servlets, JSPs and EJBs)

Valuable Resources

Users

TrustedUser

Access Control


HTTP Security High-level Overview

HTTP_GETMethod

RonPrincipal

HTTP_DELETEMethod

REQUIRES

WebResourceAccount.html

PermissionSavings Create

Permission

Savings ReadHAS

checkPermissions

Ron can view Account.htmlRon cannot delete Account.html

Permission

Savings Remove Permission

Savings Read


An authenticated principal will be associated with a set of permissions (or capabilities).

Protected resources will be associated with a set of required permissions. The presentation of any of these required permissions by the requesting principal enables the request (method) to be performed.


Delegation


Delegation is the process of forwarding a principal's credentials with cascaded downstream requests that occur within the context of work that the principal originated, or under whose behalf the downstream work is being performed.

Delegation Example

Object A Object B Object C



RunAsMode: CLIENT_IDENTITY

RunAsMode: SPECIFIED_IDENTITY RunAsIdentity: userID

RunAsMode: SYSTEM_IDENTITY

userA

userA

userA

userA

server id: serverB

server id: serverB

server id: serverB

userID

serverB


In this example, Object A starts Object B which in turn starts Object C. The identity under which the method "fooBar()" on Object B is started is "userA".

Object B resides within a server which initiates under the identity "serverB".

The figure depicts the identity under which method invocation is performed depending on the specified delegation policy.

NOTE: Delegation configuration takes place when the EJB is set up.

Sample Delegation Policy Specification

Bean Method Delegation Mode Delegation IdentityAccountBean getBalance() CLIENT

setBalance() CLIENTwithdraw() SYSTEMdeposit() SYSTEMtransferToAnotherBank() SPECIFIED middle_man


Possible Scenario on Delegation Policy Specification

lookupAccountBalance

saveRecord

executeTransfer

AccountBean SavingsAccountBean

BankBeanRon

server ID: bankAdmin

getBalance

Ron

transferToAnotherBank

withdraw bankAdmin

middle_man



Encryption


Encryption Used by Network Security

Encryption transforms data into a form that is unreadable by anyone who does not have the correct decryption method.

Unauthorized parties can still intercept the information. However, without the correct decryption method, the information is not readable.


Symetric/Secret Key (DES)

In shared/secret key (symmetric) cryptography, one key is a shared secret between two communicating parties. Encryption and decryption both use the same key.

Distributed Computing Environment (DCE) provides encryption by using Data Encryption Standard (DES) algorithms.


Asymetric Key (Public/Private Key)

In asymmetric key cryptography, a person has a public key and a private key.

A message that is encrypted with someone's public key can be decrypted only with the associated private key. Asymetric key cryptography also works in decrypting a private key with a the associated public key.


SSL

Secure Socket Layers (SSL) is a hybrid of asymmetric and symmetric key encryption

Create a "secure" sessionCan span multiple TCP connectionsAlgorithm independent - Supports multiple encryption, signing algorithms


SSL Flow

Server Hello ** Certificate** ServerKeyExchange** Certificate RequestFinished

https://host/doc.html Client Hello

Client

Client

Client

Client

Server

Server

Server

Server

Generates SymmetricKey

Client ServerData Flows...

** CertificateClientKeyExchange** Certificate VerifyChange CipherSpecFinished

ChangeCipherSpecFinished

** Optional - Situation dependent


Certificates (X509v3)

Version Identifies the version of the Certificate Format ( 0, 1, 2 )

Serial Number An integer which uniquely identifies the certificate among all the certificates that are issued by a given CA (Certification Authority) (123456)

Signature Algorithm Specifies the object identifier and parameters for the hash algorithm and signature algorithm that are used to sign this certificate (DSA with SHA-1, xxxxxx)

Issuer The distinguished name of the CA that signed the certificate (C=US, S=TX, OU=OSC...)

Validity Specifies that the start and end dates for this certificate are valid (1/1/98 - 1/1/99)Subject The distinguished name of the entity for which this certificate is bound (C=US,

S=TX, OU=OSC, CN=Louise Hand) (Version 3 has flexibility)Subject Public Key Info Contains the object identifier for the asymmetric algorithm, the parameters that

are used with the algorithm, and the public components that are used with the algorithm (RSA, 1024, xxxx)

Issuer Unique ID (v2) Optional, a string that is used to uniquely identify the Issuer (xxxxxxxxxxxxxxx)

Subject Unique ID (v2) Optional, a string that is used to uniquely identify the Subject (yyyyyyyyyyyyyyyy)

Extensions (v3) Optional fields which may be designated as critical

Signature The digital signature that is applied to the certificate


The Verisign list is not updated in the browser. Valid certificates are accepted because they are signed with a Verisign key, and because the browser understands the Verisign key.

Certification Authorities (Key Management)

A CA is trusted to identify the subject correctly and bind the Subject's public key to the Subject's name.A CA must handle certificate revocation (break the binding) and manage a Certificate Revocation List (CRL) in the directory. A CA does NOT imply the Subject is trustworthy.

CA Subject Browser

Time

Subject Browser

CRLSubject

Subject Browser

Issue a Certificate

RevokeCertificate

Talk withSubject

Talk withSubject


SSL Performance

Client

Client

Client

Server

Server

Server

GET /2Kpage.html HTTP/1.1

Client Delay = n1 + ZServer Delay = n2No Cache

Normal GET request

No CacheInitial SSL Get request

No CacheSSL Get RequestKeep-Alive


Client Delay = (46.5 * n1) + ZServer Delay = (2.5 * n2)


Client Delay = (1.1 * n1) + ZServer Delay = (1.2 * n2)

No Load on Server Server side Certificates only


The first example shows the baseline information.

The second example shows the performance of the initial request.

The third example shows the steady state.


Introduction of WebSphere Security


JVM (1.1.7)JVM (1.1.7)

Java 1.1 Security ClassesJava 1.1 Security Classes

Operating System SecurityOperating System Security

WebSphere WebSphere SecuritySecurity

HTMLCGIsServlets/JSPsEJBs

WebSphere Resources

access control

WebSphere Security

Java Security

Platform Security

CORBA SecurityCORBA Security

EJB SecurityEJB Security

Security Layers


Operating System Security: The operation systems can provide certain support services to the WebSphere Security Application. In particular, the User Registry services of the Security Server, which contains definitions of Security Principals, can be directly obtained from the operating system's User Registry (for example, NT Security Access Manager - SAM).

JVM v1.1.7: Provides the Java Security foundation.

CORBA Security: Calls made between ORBs are invoked over a Secure Association Service layer which sets up the security context and necessary quality of protection. After the session is established, the call is passed up to the EJB layer.

EJB Security: This is enforced thorough using a Security collaborator which communicates with the Security Server for authentication and authorization services.

WebSphere Security: Provides security for Web resources and EJBs in a unified manner.

Conclusion

Security is a very important part of the Application Framework for e-business.

Developing an all-encompassing security plan should be the first step.

Education is critical.



WebSphere Security

08/09/00 © Copyright 2000 IBM Corporation WebSphere_Security.prz 1

WebSphere Application Server provides a security application that works with the servlet engine and the Web server to provide access control to Web resources, including HTML pages, CGI-BIN programs, servlets, JavaServer Pages (JSP) files, and enterprise beans.

The security application provides centralized security policy control and security services, such as authentication and authorization.

WebSphere Application Server can authenticate users against the users already defined by your Lightweight Directory Access Protocol (LDAP) service or underlying operating system.

Both basic and certificate authentication are available, depending on the Web server capabilities and other factors.

Certificate authentication provides a highly secure, unobtrusive mechanism for protecting Web resources.

J a v a C l i e n tA p p l i c a t i o n

W e b A p p l i c a t i o nS e r v e r

Web Browser

Server

Client

Local

LTPA

resources nothandled by WebSphere

SecurityServer

Native OperatingSystem

Repository

LDAP

Security Plugin

for servlet and JSP requests

SAS

auth mech = LTPA

auth mech = LocalOS

CollaboratorEJS Security

WebCollaborator

EJS

AdminServer

Rel 3.5 Advanced Edition Security Flow

Rel 3.5 Advanced Edition Security Flow


The key to the WebSphere 3.x Security architecture is the central "security application" that runs in the administrative server. It provides the services for authentication and authorization for the Web server (for HTML files and JSP files), for the servlet engines, and for the EJB server.

The authorization information is maintained in the shared AdminServer database. Thus this is a "logical" centralized security server.

Note that the call to the security application occurs before the call to the resource. If a resource is protected but not started, the user will still need to authenticate.

Enterprise Application

WebSphere Security is based on the concept of an enterprise application

An enterprise application may contain any of the following:Static HTML filesJSPsServletsEJBs


EJB

EnterpriseApplication

0..*

0..*

VirtualHost

hosts

WebResourcefilename

WebApplications

0..*

0..1

virtual host

0..*

0..1

0..*

applications

Servlet

0..*

WebSphere Application Model


Creating an Enterprise Application


An enterprise is a grouping for security purposes.

Creating an Enterprise Application, continued












Creating an Enterprise Application, concluded


Security Processes

There are two main aspects involved in enterprise application security:

AuthenticationAuthorization/Delegation


Authentication

Authentication: Tell a server who you are, or simply "login"

Challenge Mechanism (how to obtain authentication data)

Authentication Mechanism (LTPA or Native OS)

User Registry (associates Credentials with Principle)

Authenticated

ChallengeChallengeMechanismMechanism

challenge user

AuthenticationAuthenticationMechanismMechanism

Authentication Data(uid/pw,cert,token)

User Registry

AuthenticationData Credentials

CredentialsCredentialsAuthenticated


LTPA is short for Lightweight Third Party Authentication.

Authentication data may be userid/password pair, a certificate, or a token.

Challenge Type Authentication Mechanism User Registry Client Support

None None None Web, JavaBasic Native OS Native OS Web, Java

LTPA LDAP Web, JavaCertificate LTPA (trusted

delegation- similar to Kerberos)

LDAP (credential mapping)

Web

Authentication Supported in WSS/WSA

IBM Secure Way DirectoryDomino 4.6, 5.0Netscape Enterprise ServerOthers (using custom configuration)

User Registries Supported in WSS/WSA 3.xLDAPNative OS

NT Domain, NT WorkGroupAIX (etc/passwd)Solaris (etc/passwd)

OS/400

Authentication Support


Java clients refer to standalone Java applications and Applets.

There is also a "custom" challenge type support for Authentication.

Challenge Types and Authentication Policies

Each Enterprise Application has a challenge type

How the user is authenticated to the Security applicationHow to get credentials

Each WebSphere Administrative Server Group has an Authentication Policy associated with it

Maps to a User RegistryHow to verify credentials


Challenge Types

Basic (HTTP User ID/Password)

Custom (User-provided HTML pages)

Certificate

None


A challenge mechanism is the method used by the server to obtain authentication from the user.

Basic authentication uses communication between the Web server and the browser to bring up a challenge dialog -- the username and password that is sent is encoded through HTTP headers.

Custom Authentication is roll your own -- you do whatever you want by using the basic servlet functionality.

Certificate authentication involves passing an encrypted certificate from client to server. This is the SSL client authentication protocol. WebSphere supports it mostly through the underlying support of the Web server.

Basic Challenge

When the browser accesses a secured resource, the server returns a 401 (unauthorized client error)

A challenge pop-up window comes up automatically from the browser

The pop-up window takes as input userid and password

NOTE: This is sent to the server as base-64 encoded

The infrastructure (Browser, Web server) provides the mechanism support


This is part of the HTTP protocol. The server will return a 401 (unauthorized client error) code and the WWW_Authenticate header to the Browser.

The client then returns the userid and password as part of the "Authorization" HTTP header.

Custom Challenge

Use form fields to obtain authorization information

Developers can control when and where to request the authentication information, and how to store and organize the information

Hand-coded servlets take care of authentication (who you are)


The custom challenge is useful when one wants to configure the server to use an HTML form to retrieve userID and password (as opposed to sending a 401 as in "Basic" challenge type). You need to specify the URL that will redirect the user and authenticate him.

Custom (Code)

<html><head> <title>Custom Login Sample</title></head><body><strong>WAS 3.x Std/Adv</strong><h2>Custom Login Sample</h2><FORM METHOD=POST ACTION="/servlet/CustomLoginServlet"><p align="left"><font size="2"><em><strong>Please Enter:</strong></em><br></font></p><strong>UserName</strong><input type="text" size="20" name="userid"><br><strong>Password</strong><input type="password" size="20" name="password"><br><br><em><strong> Jump To:</strong></em> <select name="jumpto" size="1"> <option selected>http://ratnam.raleigh.ibm.com/servlet/snoop</option> <option>http://ratnam.raleigh.ibm.com/servlet/hello</option> </select><p align="center"><input type="submit" name="login" value="Login"></p></form></body></html>


Certificate-Based Challenge

Web server configured to perform mutual authentication over SSL

Client is required to present a certificate in order to establish connection

Credentials from X.509 Certificate presented to the User Registry


This will be supported only through SSL V3.0 with client certificates.

Unobtrusive to user, but extra work to configure client certificate ahead of time.

Coding Example: Configuration of Certificate Challenge

// Get the Client CertificateX509Cert certChain[ ] = (X509Cert[ ] ) req.getAttribute("javax.net.ssl.peer_certificates") ;

// Find out who issued the certificateX500Name certIssurer = certChain(0).getIssuerName( ) ;

// Find out if an SSL Session is establishedboolean isSSLActive = ( (reg,getAttribute("javax.net.ssl.session") ) ! = null) ;

// Get the protocol that is used by the requesting URLString urlProtocol = (String)req.getProtocol( ) ;

// Get the schemeString authScheme = (String)req.getScheme( ) ;


The listed code fragments illustrate how a client certificate is accessed along with related information.

None: No Challenge Type

The security runtime does not challenge the user in any way.

If the resource is protected, authentication will fail and the resource will not be obtained.


SSL Constraint

A constraint may be specified in WebSphere 3.x as a part of the authentication policy that requires SSL to access the enterprise application.

If the application is accessed without using SSL, access will be denied.


This option is to provide data confidentiality and integrity for the information flowing between the server and a client.

Authentication Mechanism

An Authentication Mechanism validates authentication data against an associated User Registry

IBM WebSphere V3.x supports two authentication mechanisms:

Native Operating SystemLightweight Third Party Authentication (LTPA)


Native Operating System

Authentication is performed by calling native routines which result in authentication of the given data.

Authentication must run under privileged system identity:

AIX/Solaris --> rootNT --> user must have "Act as part of operating system" privilege.AS/400 does NOT require any special permissions


LTPA

The user is authenticated against a trusted third party server that is running LDAP.

The security application searches the LDAP registry for a user and performs a bind() on the user's distinguished name (DN) and password.

A successful bind results in an LTPA token being issued to the user.


Subsequent requests are authenticated against the LTPA token.

The LTPA token is digitally signed by using the LTPA server's symmetric key.

LTPA tokens have an expiration time that is configurable -- this makes it more difficult to "steal" a token. However, LTPA is still vulnerable to "replay" attacks.

These LTPA tokens and the API to LTPA are what makes single-signon for multiple applications available.

LTPA and LDAP with Certification

Security Server that hosts the Ltpa Server

WebSphere Web Server-A

challenge user for authentication

user authenticates

create authToken cookie ;serve the request

request

authenticate(authenticationData)

1

3

42

5

7

verify userid/passwordusing a LDAP user registry

storeduser info

issue authentication token6


A user submits a request to a Web server for a resource. If the requested resource is protected, the Web server determines the authentication policy associated with the resource.

The Web server then challenges the user (event 2) for authentication information based on the specified challenge mechanism (username and password, or certificate).

The user responds to the challenge by providing the authentication information. This forms the event 3.

On receiving the authentication information, the Web server contacts the Security Application (that wraps an LtpaServer) and provides the authentication information, as in event 4. On successful authentication, the token server issues a token for the user to the Web server. Authentication by LtpaServer is transparent to users.

When a request for authentication comes in from a Web server, the LtpaServer will use the configured LDAP user registry to authenticate the user (event 5).

If the user is considered authentic, the LtpaServer issues an LtpaToken to the client (event 6).

On successful authentication, the Web server receives the token issued to the user. The Web server then serves the requested resource to the authenticated user (event 7). The Web server also stores the token on the user's browser as an HTTP cookie.

LTPA System Architecture


Currently the "Third-party security server" resides in the Administrative Server.

For multiple servers, the key element in a client can authenticate on one server, be presented a token (as a cookie) -- and then be validated silently on another server, for example, a different WebSphere domain, a net.commerce server, ...

Security Considerations - Replay Attacks

An LTPA token is prone to replay attack if someone can obtain the authentication token.

SSL can be used to prevent anyone from acquiring the token from the network flow.

LTPA assumes client machines are secure, and that tokens cannot be "stolen".


Security Considerations - Off-line Attacks

An LTPA token can be prone to off-line attacks if the same private key is used for a considerable period of time.

Off-line attacks may break the key.

Keys can be generated periodically by the administrator.


HTTP Single Signon

When you use LTPA, you can enable an HTTP Single Signon to preserve a user authentication across multiple HTTP requests

HTTP Single Signon can pass credential information between applications in a single domain

Between cooperating but disparate Web serversBetween cooperating applications such as IBM OnDemand Server or IBM NT Suites


HTTP Single Signon

A single signon token is created and encrypted by using LTPA server's symmetric key

Products that share the key can decrypt the tokenand retrieve the credentials

WebSphere has the capability to export its keys,or import keys from another source.


HTTP Single Sign-On Token

CookieName = "<SharedName>Token"CookieValue = Base64Encoded (3DES Encrypted (SSOToken))SSOToken = UserData+"%"+TokenCreationTimeStampExpirationDateUserData = User information in attribute-value pairs delimited by "$" for example, "u" +":" + user ID + "$" + "p" + ":" + password (':',"$' and '%' must be escaped in the user ID and password)TokenCreationTimeStamp = Server uses this timestamp to determine if the token has expired. It is assumed each server product will have a parameter that specifies the life of a SSO Token.


User Registry

The User Registry is a view of a User Domain where the user and group information is stored.

IBM WebSphere 3.x supports two user registry types:

Native Operating SystemLDAP


Native OS Registry

Used with Native OS Authentication Mechanism

Authenticate against:Solaris User RegistryAIX User RegistryNT User RegistryAS/400 User Registry


LDAP Registry

Used with LTPA Authentication Mechanism Supported Directory Services:

IBM SecureWay Directory 3.1.1.5Domino 4.6 and 5.0Netscape Enterprise ServerOthers by using custom configuration


1. Native OS

2. LDAP

DB2

NetScape

NTAIX Solaris

Workgroup Domain

SecureWay Domino Other

AS/400

Authentication Mechanism Implementations


Steps to Enabling Security Tasks

Enabling Security - Setting global security settings

Configure security for individual applications

Create method groups to protect resources

Assign HTTP and EJB methods to method groups

Specify who can access application method groups


Enabling Security


Enabling Security, continued


The "Enable Security" checkbox on the General tabbed page of the Specify Global Settings task enables security. If this box is not checked, security settings are ignored.

Global settings include the Cachetimeout of the security system and the authentication mechanism.

Cache time-out specifies how many seconds that the servers should cache the security information that is received from the user registry or the directory service.

The higher the cache time-out, the better the performance. However, it will take longer for the changes to take affect.



Settings on the Application Defaults tab can be overridden for each application. This tab sets the default choice when configuring a new secured application.

Single signon support is based on the Realm name. If a user logs on one realm and then tries to access an application in another realm, the user will be prompted to login to the second realm.

In WebSphere 3.x, all applications in a server group must belong to the same realm. This limitation will be lifted in a future release.

The "Use SSL to connect client and WebSphere" constraint requires SSL support to be configured for your Web Server.

Enabling Security, continuedLocal OS Authentication Mechanism


Enable Single Sign On: Enabling Single Sign On (SSO) tells LTPA to store extra information in the tokens so that otherapplications can accept clients as already authenticated by WebSphere Application Server. When clients try to access theother applications, they will not be interrupted and asked to log in. WebSphere Application Server Version 3.5 introduces support for Single Sign On with Domino Server. WebSphere Application Server can import and export keys and provide a Single Sign On between the WebSphere Application Server and Domino environments.

Enabling Security, continuedLocal OS Authentication Mechanism


This userID and password are used to delegate the EJB type - SYSTEM.

The User Registry tab changes based on what is selected on the Authentication Mechanism tab.

The userID and password on the User Registry tab allow the security server to access the native methods for authentication.

On AIX and Solaris, the user must have root access or permissions.On NT, the user must have "Act as part of operating system" rights.

If the authentication mechanism is Native Operating System and if the operating system in Windows NT:

The userID that is associated with the WebSphere should be different that the machine name. For example, if the machine name is "ciber", then the server ID should not be "ciber".

If the machine is part of a NT domain, then the userID that is associated with the WebSphere must be a valid ID in that domain.


LTPA Authentication Mechanism




This userID and password are used to delegate the EJB type - SYSTEM.

The userid and password on the User Registry tab are used to access the LDAP directory.

Select the desired type of directory from the "Directory Type" drop down menu.

Specialized LDAP configuration settings are available under the Advanced... button. For more information, see:www.ibm.com/software/webservers/appserv/doc/v30/ae/web/help/secure3.htm#vreg.

Enabling Security, concluded



Set global security settings






Configuring Security


Configuring Security, continued




Note that this tab is very similar to the Application Defaults tab in Specify Global Settings.



type - SPECIFIED.Application Identity - User ID Specifies the user ID under which the application will run. The ID is used for delegation of the application's resources.

Application Identity - Password Specifies a password for the Application Identity.





Configuring Security, concluded


Secured Resources

Web Resources (HTML, JSP) - HTTP permissions

Servlets - Servlet Sandbox permissions

EJBs - method-level access and delegation


What can be secured in WebSphere:

(1) Web Resources (HTML pages, JSP pages, Servlets) can be secured by their HTTP permissions. A user may have permission to POST to a JSP page, but not DELETE it, or GET but not POST. Servlets also have these permissions. WebSphere works with the Web server to secure Web resources.

NOTE: Static HTML pages must be served by WebSphere (not the HTTP server) for WebSphere to protect them. Use the WebSphere file-serving servlet as configured in the Deployment labs.

(2) Servlets run in a Servlet Sandbox that controls their ability to read/write files, connection/listen to sockets, link in native code (JNI), execute programs and access system properties. These can be applied on the user, servlet or application basis.

(3) EJBs can have access permissions for users and roles on a per-method basis. There is also the notion of delegation (run-as) in EJBs.

Protection Defaults

When security is enabled:Web resources are unprotected (by default) EJBs are protected


You can explicitly "unprotect" an EJB. Add the EJB to an application, specify security for the application (this actually protects the EJB), configure resource security for the EJB, but then give permission to EVERYONE to access the EJB.

Method Groups

Method groups are categories of methods, grouped for the purpose of assigning permissions for the method group as a whole

Example: user megan has access to any read-only method, but not write methods


Method Groups are Named permissionsAssociated with PrinciplesRequired by resources

Can accept default method groups, or customize them

Method Groups, continued









Working with Method Groups














Assign Methods to Method Groups

WebSphere can assign your methods to one of WebSphere's method groups.

You can assign all methods to groups manually.

You can combine the above two options.



During the configure resource security task,WebSphere prompts:

If you select "yes", WebSphere assigns methods to method groups based on the rules that are listed on the previous slide.


If the Web resource method is ...

Or the object method name starts with ...

The required right (method group) is ...

GET or POST GET READPUT SET WRITE

CREATE CREATEejbCreate CREATE

DELETE REMOVE DELETEejbRemove DELETEejbFindByPrimaryKey FINDER(all other) EXECUTE

Mapping Method Name to Required Rights


Servlets/JSPs/HTMLs

HTTP_Delete = Remove MethodsHTTP_Get = Read MethodsHTTP_Post = Read MethodsHTTP_Put = Write Methods

EJBs

ejbCreate = Create MethodsejbfindByPrimarykey = Finder MethodsejbRemove = Remove Methodsget * = Read Methodsset * = Write Methodsall others = Execute Methods


If you choose not to let WebSphere assign your methods to method groups. However, if you choose to let WebSphere assign your methods to method groups, but want to make changes, a list of methods for the resource is displayed.

You can add the methods to the method groups of your choice.


EJB Delegation

Delegation is specified as part of the configure resource security task for EJBs.

Delegation Policy is specified in terms of the RunAs Policy.

The RunAs Policy consists of two partsRunAs ModeMapped Application Identity


RunAs Mode

RunAs Mode applies to EJB methodsDefined by deployment descriptor of EJB; deployment descriptor initially sets the valuesCan be overwritten by using the Administrative ConsoleValid values:

SYSTEMCLIENTSPECIFIED


RunAsMode - Specifies whether a method should initiate with the Principal of the caller (CLIENT_IDENTITY), the Principal of the System (SYSTEM_IDENTITY [which is the userID from the User Registry tab of the Global Settings task]), or a specified Principal (SPECIFIED_IDENTITY [which is the userID from the Application Security task]).

Mapped Application Identity

Mapped Application IdentitySpecifies the security identity under which the EJB method will be executedApplies only when RunAs Mode is set to SPECIFIEDSelection list of identities of enterprise applications of which EJB is a member


In WebSphere 3.x, EJB methods are mapped to application identities rather than to RunAs identities for methods that have RunAs Modes of SPECIFIED.





Configure Resource Security - Assign HTTP and EJB methods to method groups



Resource Security


Resource Security


Select to apply resource security to an EJB.

Resource Security


EJB methods.

Resource Security


Delegation


EJB delegation

RunAs Mode features are accessed by using the Security Configure Resource Security task.

NOTE: Web resources do not have a similar screen.

Resource Security


Resource Security


Resource Security


Resource Security


Setting Access Control

Every Enterprise application/method group pair represents a permission that either a user has or does not have

Example: application Big3SecurityBig3Security-ReadMethodsBig3Security-WriteMethodsBig3Security-RemoveMethodsBig3Security-CreateMethodsBig3Security-FinderMethodsBig3Security-ExecuteMethods


HTTP Security High-level Overview

HTTP_GETMethod

RonPrincipal

HTTP_DELETEMethod

REQUIRES

WebResourceAccount.html

PermissionSavings Create

Permission

Savings ReadHAS

checkPermissions

Ron can view Account.htmlRon cannot delete Account.html

Permission

Savings Remove Permission

Savings Read


An authenticated principal will be associated with a set of permissions (or capabilities).

Protected resources will be associated with a set of required permissions. The presentation of any of these required permissions by the requesting principal enables the request (method) to be performed.

When a browser requests a static HTML page (HTML file, CGI-BIN, and so on) the Web server must determine if the page is protected. This determination is done in the Security Plug-in by using the security data that is acquired from the security server.

This illustrates an example where the Account.html page is determined to be protected, hence the authentication policy (which is part of the security data acquired from the Security Server) is conferred. Based on the policy attached to the Account.html resource, it is decided to challenge the user for his identity by using basic HTTP authentication. Once basic authentication is successfully performed, authentication data (for example, principle name, Ron, and his password, blah) is available to determine if the principal Ron has the required permission. AccountRead, to perform the HTTP_GET method, on the desired web resource.

Protecting Resources

/hello.html /servlet/account /account.html

alice HTTP_GETbob HTTP_GET, HTTP_PUT HTTP_GET HTTP_GET

charlie HTTP_GET HTTP_GET

The authorization policy matrix shows resources and principalsThe intersection "cells" represent the access policy for principal on a particular resourceAssociating a column of data with the resource (Access Control List)Associating a row of data with a principal (Capability)


In WebSphere, the authorization model is based on the classical Capability model. This is different from the Access Control Model supported in 2.0. In Capability model, permissions that are required to perform a particular operation are associated with a principal. In the case of Access Control Model, principal and the operation they can perform are associated with the resources themselves.

Consider an authorization policy that specifies a protection matrix depicted in the table on the slide. Access control list is a column-based view of the protection matrix. It specifies that the resource hello.html can be accessed by alice and bob. On the other hand, a Capability model is a row-based view of the above matrix. Capability Model specifies that the user alice has permissions to perform HTTP_GET on resource /hello.html.

To further aid in the implementation, resources are associated with Enterprise Applications and operations (methods) are grouped together in "Method Groups".

Thus each principal will have a list of Permissions which are <Application, MethodGroup> tuples. While each resource will have a "requires permission" set.

Capability Model

Principal Permissions

alice { (HelloApp, ReadMethods) }

bob { (HelloApp, ReadMethods), (HelloApp, WriteMethods), AccountApp, ReadMethods)}

charlie { (AccountApp, ReadMethods)}


In WebSphere 3.x, a permission is based on the requested operation and the requested resources. For ease of administration, resources are grouped into applications and methods are grouped into method groups. The {application, method group} tuple constitute the permission that is required to invoke a method on a resource. Thus permissions are automatically formed once resources are mapped to applications and methods are mapped into method groups. Process of "granting" those permissions to principals is performed by using the administration tool.

During runtime, based on the requested operation on a resource, a set of permissions is considered to be the "required" permissions. If the requesting principal has been granted at least one of the required permissions, then the security subsystem authorizes the request to be processed.

Consider that hello.html is part of HelloApp application and the HTTP_GET is a part of the ReadMethods method group. Also, let /servlet/account and /account.html be a part of AccountApp application. Given these configuration and desired permissions specified in the previous table, the table on this slide illustrates how permissions are stored in WebSphere 3.x.

Assigning Permissions

Assign users, groups or roles to application/method group pairs

Adding groups is more practical

Roles can be used if authentication service provides them


You use the Assign Permissions task to assign permissions to users and groups.

You may need to stop and restart the administrative server for changes to take effect. However, you may wait for the security cache time-out value to complete.






Assign Permissions - Specify who can access application method groups


Assigning Permissions, continued












Assigning Permissions, concluded


OSAuthentication LTPAAuthentication

MethodDelegationPolicy

Principal

MethodGroup

AuthenticationPolicy ApplicationSecuritychallengeType

Permission principal

method group

EnterpriseApplicationServer* +deployed to+deployed on

applications

* The server isthe Admin Server

Security Model


A few things to point out:

Permissions are by method group and principalChallenge is by Enterprise ApplicationUser Registry is by WebSphere Admin Server

Security Trace

Authentication and authorization failures are traced by default in WebSphere 3.x For additional information and trace, the tracing should be turned on at the com.ibm.ejs.security package level through the System Management tracefacility. If the trace is turned on the application server, you will see a listing thatcontains trace messages as shown below:

098.402 12481c EJSWebCollabo A Authorization.failed.for.???.while.invoking.(default_host)/servlet/hello.GET

The above line indicates that authorization failed for a user "???" when a HTTPGET method started on the hello servlet. The "???" indicates that anunauthenticated user has tried to access the protected servlet. If authorizationfails for an authenticated user, the trace message would look similar to:

098.402 12481c EJSWebCollabo A Authorization.failed.for.'ron'.while.invoking.(default_host)/servlet/hello.GET


Programmatic Login

Developers who do not want to prompt the user by using a 401 dialog window in the case of a HTTP client (Web browser), or by using a dialog box in the case of a pure Java client, can programmatically login based on a userID/password retrieved through some other means such as an HTML form.

Programmatic login can be broadly classified into two categories that are based on where the actual authentication takes place, namely the client side login, and the server side login.

See Programmatic Login Appendix (Appendix C).


Table of Contents for Appendix C

Login URL file: login.htmlServlets that performs login and exploits Single Sign-On

AbstractLoginServletCustomLoginServletdoPost Method postLogin MethodcheckParams showInvalidParameterPage

Client Side LoginTestClientServerSideAuthenticatorLoginHelper

Form-Based LoginSSOAuthenticator Object

Server Side LoginServerSideAuthenticator

Obtaining Identity InformationLimitations



Accessing Secured Applications


You can access EJBs in the following ways:

From a servlet or JSPFrom a Java client

When you access an EJB from a servlet or JSP, WebSphere handles the delegation of credentials.

Follow the process presented here to access an EJB from a Java client.

Create a text file and specifythe necessary property-value pairs

com.ibm.CORBA.SSLKeyRing=com.ibm.websphere.DummyKeyring (You can substitute your own keyring for the dummy keyring)

com.ibm.CORBA.SSLKeyRingPassword=WebAS(You can use the password for your custom keyring)

com.ibm.CORBA.securityEnabled=true

The First Step


You can use the sas.client.props in the WebSphere Application Server installation as a model.

The first property is required only when you use digital certificates (a dummy keyring option) as an authentication option.

NOTE: The dummy keyring is not intended for use in a production environment.

When starting the client in preparation of accessing a secured resource such as an enterprise bean, add the following to the command line:

-Dcom.ibm.CORBA.ConfigURL=URL of properties file created on last slide

Add the command after the "java" command and before the application class name. For example, you would specify:

java -Dcom.ibm.CORBA.client.ConfigURL=file:/install_root/properties/my.client.props MyClientApp

provided that the client was named "MyClientApp" and that the created "my.client.prop" exists in the properties directory of the Application Server installation root.

The Final Steps


Note that the Abstract Windowing Toolkit (AWT) library generates non-daemon threads to handle screen updates, event queues, and so forth. These threads remain active even when the AWT object is no longer in use (no more references made to the object), or when the AWT object has stopped. By convention, the Java Virtual Machine (JVM) will not end if there are non-daemon threads which are still active. It may appear as though the application has hung, and will not complete. At this time, the only known method of closing these threads is to use the System.exit(0) command at the end of the "main" method of the application class.

When enabling security for client applications, the client principle will be presented with a login panel that prompts for a userid and password. The login panel uses AWT. Therefore using the System.exit(0) command at the end of the "main" method of the application class allows it to stop the AWT threads and exit after completion.

Cautionary Notice


Conclusion

Application server security mustIdentify the client invoking the EJB methodDetermine which permissions the client needs to invoke the methodDetermine whether the client has the necessary permissionsConsult the delegation policy to determine the identity under which the method should be executed


IBM WEBSPHERE WORKSHOP - LAB EXERCISE

Enabling WebSphere Security

What This Exercise is About

In this exercise, you will create an enterprise application and apply Local operating system (OS)authentication to use the basic userid/password challenge.

User Requirement

You must have Big3 configured in the WebSphere Administrative Server.

What You Should Be Able to Do

After completing the lab, you will be able to enable Local OS security for an enterpriseapplication.

Introduction

In this lab you will create an enterprise application for the Big3Server resources. These includethe enterprise beans and Web application that were created in the previous exercise. You willuse the administrative console to specify global security settings for the WebSphereadministrative server, and then configure the access levels to the different resources that areincluded within the enterprise application.

Exercise Instructions

This lab will be performed on the AIX machine. Estimated Time: 1 hour 15 minutes

Verify that the WebSphere Administrative Server and administrative console are running. Toverify that the Administrative Server is running, open a terminal window and type the command:

ps -ef | grep java

If an entry displays a classpath that contains “admin.config” then the Administrative Server isrunning.

© Copyright IBM Corporation. 2000. All rights reserved.

2000/07/31 10:17:40 IBM WebSphere Workshop - Lab Exercise Enabling_Security_Lab_35.lwpPage 1 of 12

Part One: Creating an Enterprise Application

You will create the enterprise application by using the administrator’s console.

__1. From the wizard icon , select the down arrow to obtain the menu,

or click Console --> Tasks to obtain the menu.

__2. Click the entry for Create Enterprise Application.

__3. Specify Big3Security as the name of the enterprise application. Click Next.

NOTE: Each application name has to be unique within the administrative domain.Enterprise applications are contained by administrative domains, and are not specificnodes within a domain. An administrative domain is a collection of one or more nodeswhose administrative servers share an administrative repository.



__4. The next screen allows you to add resources to the Big3 enterprise application. Expandthe Enterprise Beans folder to add the ProcessClaimBean, PolicyBean, andClaimBean.

__5. Select one bean at a time and click the Add... button. Each time you should see aconfirmation message in the console messages section of the administrator’s consolewhich indicates that the bean was added successfully.

__6. Add the Big3WebApp that is located under the entry for Web Applications.

__7. Click Next. This screen allows you to remove resources from the Big3 enterpriseapplication. No resources will be removed as part of this lab exercise.



__8. Click Finish to complete the creation of the enterprise application. You will receive aconfirmation dialog window.

__9. Click the Topology icon and locate the entry for the Big3 enterprise application.The Big3 application is contained by the administrative domain and is not part of anynode.

The Big3 application properties can only be viewed from the Topology view. You need touse the Edit Enterprise Application task to modify the properties.



NOTE: The enterprise application can be started or stopped. This stops or starts allof the resources that are encapsulated by the enterprise application. Because ofsome problems which may occur when starting the enterprise application, it isrecommended that you leave the enterprise application in the stopped state and startor start the application server as you have in the previous labs.

Part Two: Configuring Global Security

Global Security Settings are the settings that all existing and future applications will useby default.

__1. From the Tasks menu, click the Configure Global Security Settings choice to activatethe wizard.

__2. The General tab allows you to enable or disable security in WebSphere. Select theEnable Security checkbox.

NOTE: All other security settings will be ignored if this is not set.

__3. Click the Application Defaults tab. The settings on this page are the default securitysettings that each application will inherit while running under WebSphere. However,unlike the other global settings these can be changed for each application.

NOTE: While the Realm Name field is editable, WebSphere 3.5 supports only asingle realm per administrative domain. Accept the default realm name to avoidviolating this requirement.

__4. In the Challenge Type grouping click Basic (User ID and Password).



__5. Click the Authentication Mechanism tab to specify how to authenticate the user. SelectLocal Operating System.

__6. Click the User Registry tab to specify the userid and password for the account thathas permissions to the operating system security calls. Fill in the information for the rootaccount.

__7. Click Finish to save the Global Settings. You will see a confirmation message that indicates success, and also lets you know that the administrative server needs to bestopped and restarted before security will be enforced.

Changes to the Global Settings are the only security settings that require a restart of theadministrative server. For the purposes of this lab, we will configure the enterpriseapplication for security before restarting the server. The administrative serverneeds to be restarted each time security is enabled or disabled.

Part Three: Configuring Enterprise Application Security

__1. From the Tasks menu, activate the Configure Application Security wizard. Once thiswizard is started, a list of enterprise applications that are available for configuration willdisplay. Select the Big3Security application and click Next.



__2. Select Basic as the Challenge Type. Click Next.

__3. Click Change… to bring up search dialog for the application system user identity.

NOTE: This specifies the user ID under which the application will run. This user ID isused for the delegation of enterprise beans when the Run-AsMode is set to system inthe Configure Resource Security task.

__4. This will bring up the search dialog for the EJB delegation system identity.

__5. “User” will be selected in the search for option. Enter root in the “Search Filter” field.

__6. Click search to locate the entry for the user from the operating system user registry. Thesearch results will display the full name for the root account. Select it and click OK.



__7. Fill in the password for the root account.

__8. Click Finish to save the settings and close the Configure Application Security Wizard.

__9. From the Tasks menu, activate the Configure Resource Security wizard.

__10. Expand the entry for EnterpriseBeans and select the PolicyBean. Click Next. Amessage box displays that asks if the default method groups should be used.

__11. Click Yes.

__12. The next screen displays the PolicyBean methods. Expand the methods to see theassigned method groups.

__13. Click Next. This will display the delegation settings page. Accept the default settingsand click Finish. You should see a confirmation message in the console messagessection of the administrator’s console which indicates that the bean methods were added successfully.

__14. You have just secured the methods for the PolicyBean. Rerun the ConfigureResource Security task to protect the methods of the ClaimBean and theProcessClaimBean.



__15. Similarly, you need to configure the HTTP methods for the static HTML pages and the twoservlets. These are grouped under default_host of the Virtual Hosts folder for theConfigure Resource Security Task.

__16. Use the default method groups for securing all seven of the files that start with /Big3(/Big3/index.html, /Big3/top.html, and so forth), and the two servlets.

NOTE: If the /Big3/*.html in the Web path of the file serving enabler was configuredduring the Deployment lab, only the resource security for /Big3/*.html and the servletwould need to be configured.

__17. Activate the Configure Security Permissions wizard. Permissions are related toapplications and method groups. Select the Big3Security enterprise application andclick Next.

__18. Select all the permissions for the Big3Security application by selecting the top one, thenhold down the shift key and click the bottom one. Click Next.



__19. In the Grant Permissions window, select All Authenticated Users and click Next.

This setting will allow any user with a valid operating system account in the OS userregistry to access all the resources of the Big3 application.

__20. Click Finish. You should see a confirmation message in the console messages sectionof the administrator’s console.

__21. This completes the security configuration for the application server and the Big3enterprise application. Stop the administrative server. Right click on your node and selectStop from the pop-up menu. You will receive a confirmation dialog window. Select Yes.

__22. Start the administrative server to enable security. Open a terminal window and type:./startupServer.sh&. Once, the server is running in secured mode, you can apply anymodifications to the security settings of an enterprise application by waiting for thesecurity cache to time out.

Part Four: Testing Security

__1. As the administrative server is restarting, view the trace file (<as_root>/logs/tracefile).You will see several pages of messages regarding security. If there is a problem with thesecurity configuration, you may see authentication failures here.

__2. Ensure that security is enabled on the administrator's console. Open the<as_root>/properties/sas.client.props file and verify that the com.ibm.CORBA.securityEnabled property to “true”.

NOTE: This file is the property file for the administrative console. WebSphere is atrue client/server application so the administrative console is not tied to theadministrative server. Therefore, making changes to the server’s configuration doesnot change the client configuration.



__3. Start the administrative console by typing ./adminclient.sh on a command line. You willbe prompted for a userid and password. Enter the information for the root account.

__4. Verify that the Big3 application server is started. Refer to the deployment lab if you do notremember how to start the Big3 application server.

__5. Start your browser. Enter the following URL: http://<machine name>/Big3/index.html.WebSphere will respond with a basic authentication challenge. Enter the root userid andpassword.

NOTE: Once the userid has been authenticated, WebSphere will check to see if theuserid has Big3 Read permission. The Read permission is required to satisfy theHTTP_GET Request issued by the browse. Since, all authenticated users have beenassigned to the Big3 Read method group, the HTML page will be served.



__6. When the ProcessClaim form appears, click Submit. A message that indicates thesuccessful completion of the request should display.

Tip: You will have trouble starting a secured (security-enabled) administrative serveror an application server on a Windows NT machine if this Windows NT machine isconfigured as a part of a Windows NT domain, and is not connected through thenetwork to the domain server. Resolution: Configure the Windows NT machine so that it is not part of a Windows NTdomain.(From: http://www.ibm.com/software/webservers/appserv/doc/v30/relnotes.html)

Summary

In this lab you created an enterprise application, enabled global security, configured security foran enterprise application, and tested the security application with WebSphere enabled.

END OF EXERCISE




WebSphere Security - Modifying Permissions


In this exercise you will implement a more restrictive security scheme for the Big3 enterpriseapplication.

User Requirements

The Big3Security application needs to be configured in WebSphere and secured by using LocalOS permissions for All Authenticated Users. The following lab exercises must be completedprior to performing this lab exercise:

� Code Packaging Lab

� Deploying the Big3 Application Lab

� Enabling WebSphere Security Lab


After completing the lab you will be able to use the resource permission settings to control theauthorization level that is granted to different users.

Introduction

The security policy implemented in the previous lab allowed anyone with a valid operatingsystem user account to gain complete access to the Big3Security application. In this lab you willuse the “Assign Permissions” wizard to:

� Grant access to just one user.

� Remove the user’s right to run the execute methods.

© Copyright IBM Corporation 2000. All rights reserved

2000/07/31 10:22:17 IBM WebSphere Workshop - Lab Exercise Modifying Permissions_3_5.lwpPage 1 of 5


This exercise is performed on the AIX machine. Estimated Time: 30 minutes

Part One: Granting Access to a Single User.

__1. Start the administrator’s console if it is not loaded and logon to the console by using theuserid and password for the root account.

__2. Stop the Big3Server application server.

__3. From the Tasks menu, activate the Configure Security Permissions wizard.

__4. Verify the View by Application radio button is active, select Big3Security, and click Next.

__5. Select all of the entries and click Next.

__6. In the Search dialog, select the Selection radio button. Change the Search for criteriato User. In the Search Filter field enter root and then click Search.

__7. Select the entry for root from the search results listbox and click Next.



__8. Expand each of the permissions for the Big3Security application. The user names rootand All Authenticated Users will now appear under each of the Big3Securitypermissions.

__9. Select all the initial All Authenticated Users then hold the Ctrl button down while youselect the rest of the All Authenticated Users from the specified user list.

__10. Click Remove then Finish. This will close the wizard and return you to the main consolepanel.

__11. Start the Big3 application server.

__12. To test the authorization, start a browser and point it to http://<machinename>/Big3/index.html. At the logon prompt enter the information for the waseduaccount. This account does not have any permissions of the Big3 application assigned toit, so the logon attempt will fail.

Tip: You must shut down any previous instances of Netscape and start a new one.This ensures that the previous login does not carry over to the next access.

__13. Logon using the root userid. You should see the homepage of the Big3 application. ClickSubmit. The request should complete successfully.

Part Two: Limiting User Access

__1. Stop the Big3 application server.

__2. Start the Configure Security Permissions wizard.

__3. Select the View by Method Group radio button, the Execute Methods option, and clickNext.



__4. Select Big3Security-Execute Methods and click Next.

__5. Ignore the Grant Permissions options window by clicking Next.

__6. Expand just the Big3Security-Execute Methods permission. Select the entry for rootand click Remove.

__7. Click Finish to return to the main console.

__8. Restart the Big3 application server.

__9. Open the browser and enter the URL for the Big3 enterprise application. At the logonprompt, enter the userid and password for root.

__10. The logon attempt should succeed and display the homepage for the Big3 enterpriseapplication.

__11. Click Submit. The attempt to create a new claim request will fail. This happens becausethe user does not have the right to execute the ProcessClaimServlet.

__12. After completing the testing, reconfigure the application security settings so that allauthenticated users can access the Big3 enterprise application.



Part Three: Granting Users Access to the Administrative Console.


__2. Verify the View by Application radio button is active, select AdminApplication, and clickNext.

__3. Select all of the entries and click Next.

__4. In the Search dialog, select the Selection radio button. Change the Search for criteriato User. In the Search Filter field enter wasedu and then click Search.

__5. Select the entry for wasedu from the search results listbox and click Next.

__6. The user name wasedu will now appear under each of the Administrative Applications.

__7. Click Finish to return to the main console.

__8. Stop and restart the administrative console. Logon as wasedu.

Summary

In this lab you granted access to just one user and then removed the user’s right to run theexecute methods.

END OF EXERCISE




WAS Basic Security Using SecureWay and LDAP


In this exercise you will access the SecureWay Directory LDAP Server, and add two new usersto the directory. You will use the SecureWay configuration to enforce security and controlaccess by using an LDAP directory service.

User Requirement

Before we can use SecureWay Directory Services as a user registry, we must add users to thedirectory.


After completing this exercise you will be able to use SecureWay to work with directories,configure users, and adjust the global security settings to use an LDAP directory server as theuser registry.

Introduction

SecureWay Directory Services is an LDAP directory which can be used as a user registry forWebSphere security. In this lab, we will add users to the registry for WebSphere authentication.


Parts One through Five are performed on the NT machine. Parts Six and Seven areperformed on the AIX machine. Estimated Time: 1 hour and 35 minutes.

Part One: Creating a Default LDAPDB2 Database

__1. Stop the HTTP Server if it is running. Start --> Settings --> Control Panel --> Services--> IBM HTTP Server. Click the Stop button.

© Copyright IBM Corporation 2000. All rights reserved.

2000/08/17 08:27:52 IBM WebSphere Workshop - Lab Exercise SecureWay_LDAP_lab3_5.lwpPage 1 of 12

__2. Start the SecureWay Directory Configuration. Start --> Programs --> IBM SecureWayDirectory --> SecureWay Directory Configuration.

__3. Accept the default configuration (all three boxes should be checked) and click Next.

__4. Enter the password - was1edu and click Next.

__5. Make sure that the Create a default LDAPDB2 database radio button is selected andclick Next.

__6. Once again, make sure that the Create a default LDAPDB2 database radio button isselected and click Next.

__7. Accept the “C” drive as the default and click Next.


__8. Select IBM HTTP as the Web Server from the list and click Next.

__9. Click the Browse button to find the path to the httpd.conf file. Navigate to C:\IBM HTTPServer\conf\httpd.conf and click open.

__10. Click Next.

__11. Click the Configure button.

__12. Wait for a few minutes until the following message returns, then click OK.

__13. Restart the Web server so that the changes will take effect. Start --> Settings -->Control Panel --> Services --> IBM HTTP Server. Click the Start button.

__14. Start the IBM SecureWay Directory 3.1 Start --> Settings --> Control Panel -->Services --> IBM SecureWay Directory 3.1. Click the Start button.

Part Two: Accessing the SecureWay Directory LDAP Server

__1. Access the LDAP administration at: http://<nt_machine_name>/ldap/ and access theLDAP server through the Web based GUI.

__2. Enter the User ID (cn=root) and the associated password.

__3. Click Logon.



Part Three: Working with the Sample Directory Tree that comes with SecureWayDirectory

__1. You need to add a suffix. From the left frame of the GUI window, open the Suffixesfolder and click Add a suffix. For the sample, enter o=ibm,c=us as the Suffix DN andclick Add a new suffix.

__2. After adding the sample suffix, add the directory data. From the left frame of the GUIwindow, open the Database folder and click Add entries.

__3. Select the sample LDIF (LDAP Data Interchange Format) file and path. Click Addentries to database. Wait till all of the processing is done (about six minutes). Ifsuccessful, 50 entries should be added and you will receive a message that indicatesthis.

__4. Stop and restart the IBM SecureWay Directory 3.1 server.


NOTE: You can restart the SecureWay Directory Server through an alternative method.From the left frame of the GUI window, open the Server folder and clickStartup/Shutdown. In the right frame, click Shutdown, then click Startup.

__5. After all the entries have been added, browse the directory contents. From the left frameof the GUI window, open the Directory/Access control folder and click Browse tree.

__6. Right mouse click any of the directory entries to bring up the details in the right frame of anew browser window.

Part Four: Using the Directory Management Tool (DMT) to Add Your own Directory Entry

__1. Bring up the DMT: Start --> Programs --> IBM SecureWay Directory --> DirectoryManagement Tool

From the left frame of the GUI window, open the Server folder and click Properties.This will open the View Server Properties display. You will see that the default port of 389is being used by the LDAP server with no security.



__2. From the left frame of the GUI window, open the Server folder and click Rebind.Opening this display enables you to authenticate yourself.

__A. Select the Authenticated radio button.__B. Enter cn=root for the User DN__C. Enter the password for cn=root.__D. Click OK.

__3. As soon as you press OK, the Browse directory tree display will be displayed. To adda Rochester entry, highlight o=ibm,c=us and click Add

__4. Add a new Organizational Unit (ou) of rchland by typing ou=rchland in the Entry RDNtext field. Choose Organizational unit for the entry type. Click Next.


__5. In the Attributes display, enter rchland in the ou field. Fill in any other details that youwish. Click Create.

Part Five: Using DMT to Add a New User and Assign a Password

__1. From the Browse directory tree display, open o=ibm,c=us then highlight ou=rchlandand click Add.

__2. Choose User as the entry type and type the common name cn=wasedu in the EntryRDN field. Click Next.

__3. Enter a Common Name (wasedu) and a Last Name (test).



__4. Scroll down and type was1edu in the userPassword field. Add any other desired details.Click Create.

__5. You can test your entry and password addition by logging on to the LDAP server throughthe Web GUI by using the Common Name (cn) that you just created ofcn=wasedu,ou=rchland,o=ibm,c=us.

Part Six: Enabling Basic LDAP Security Within WebSphere

REMINDER: This part of the lab exercise is to be run on an AIX machine.

__1. Bring up the Administrative Console.

__2. Start the Configure Global Security Settings wizard.

__3. Ensure that the Enable Security checkbox on the General tab is checked, and the Challenge Type of the Application Default tab is set to Basic.

__4. In the Authentication Mechanism tab, specify Lightweight Third Party Authentication.


__5. Under the User Registry tab in the Global Settings for Security:

__A. Enter the top level Administrator DN for the Security Server ID (wasedu) and the corresponding password.__B. Choose SecureWay for the Directory Type.__C. Enter the NT machine name for the Host name.__D. Type 389 for the port.__E. Base Distinguished Name o=ibm,c=us (No spaces)__F. Click the Advanced... Button.

NOTE: Since the lab machines use IBM SecureWay Directory version 3.1.1.1 instead ofversion 2.x that is shipped with WebSphere, the Advanced... configuration option mustbe Used.

__G. Change the User Filter to (&(cn=%v)(objectclass=person)). __H. Change the User ID Map to *:cn.__I. Click OK.

NOTE: The directory type will now say Custom.

__J. Click Finish.



__6. An LTPA Password display will appear. Enter was1edu and click OK.

Wait until you receive the confirmation message before you go to the next step.

NOTE: This password will need to be given when the key file is imported by anotherapplication for single sign-on purposes.

__7. Stop and re-start the WebSphere Administrative Server.

__8. Bring up the WebSphere Administrative Console. A challenge display should now appear.

__9. Enter the sample Administrator Common Name of wasedu and the associatedpassword.

On successful validation, you will be able to work with the WebSphere AdministratorConsole. On the NT machine, access the LDAP Web GUI Directory Server frame, openthe Server folder, and click Connections to see the details of the connections.

NOTE: You must be logged into the LDAP Web GUI as cn=root to see the serverfolder.



__11. Select all of the permissions for the Big3Security Enterprise Application and access theGrant Permissions window.

__12. Enter * for the User search filter and click Search. Select wasedu from the list ofchoices and click Next.

__13. Click Finish.

__14. Stop and restart the WebSphere Administrative Server.

__15. Start the Administrative Console. Login using the wasedu user ID and password.

__16. Start the Big3Server.

__17. Bring up a Netscape window and access thehttp://<aix_machine_name>/Big3/index.html file.

__18. You should be prompted for a user name and password. Enter wasedu for the useridand password. This should successfully load the Big3 index page.

NOTE: You cannot use cn=root to access Big3 because o=ibm,c=us is the baseDistinguished Name and cn=root is not an entry under o=ibm,c=us. You can useEddie Catu with a password of secretpw. This userid and password was added tothe LDAP server when you ran the add entries command in the Web configurationtool.

__19. Click Submit. This should successfully process a claim.

__20. Close the Netscape window.

__21. Open a new Netscape window and access thehttp://<aix_machine_name>/Big3/index.html file.

__22. You should be prompted for a user name and password. Enter Eddie Catu for the useridand secretpw for the password. This should successfully load the Big3 index page.

NOTE: You can use this userid and password because they were added to the LDAPserver when you ran the add entries command in the Web configuration tool.



Part Seven: Granting access to a single user.

__1. Start the administrator’s console if it is not loaded and logon to the console by using theuserid and password for the wasedu account.

__2. Stop the Big3Server application server.


__4. Expand each of the permissions for the Big3Security application and remove the entriesfor “All Authenticated Users”.

__5. Stop and restart the Administrative Server.

NOTE: You could wait for the cache to time-out rather than stop and restart theadministrative server. The default time-out value is 600 seconds.

__6. Start the administrative console.

__7. Expand the node and start the Big3Server application server.

__8. Test the Big3 application from the browser window by using the wasedu userid. Therequest should complete successfully. Close the browser window.

__9. Test the authorization by starting a browser and pointing it to http://<aix_machinename>/Big3/index.html. At the logon prompt, enter the information for the Eddie Catuaccount from Part 6 of this lab. This account does not have any permissions to themethods of the Big3 application assigned to it, so the logon attempt will fail and return an“Authorization Failed” message.

__10. Reconfigure the application security permissions so that All Authenticated Users canaccess the Big3 application.

Summary

During the completion of this exercise you used SecureWay Directory LDAP Server to work anddirectories, configured users, and adjusted the global security settings to use an LDAP directoryserver as the user registry.

END OF EXERCISE



Enabling SSL


In this exercise you will configure the IBM HTTP server for SSL Encryption.

User Requirement

SSL is an encryption method that is used during the transfer of sensitive data.


After completing the lab you will be able to generate a self-signed digital certificate, define avirtual host in the IBM HTTP Server and configure the server for SSL encryption.

Introduction

SSL requires a server side digital certificate to encrypt the data. For the purposes of this lab aself signed certificate will be used. In the production environment, the IKEYMAN utility that isincluded with the IBM HTTP Server can be used to request a certificate from an externalCertificate Authority (CA) and to install it in the certificate database. A virtual host will be definedby manually editing the httpd.conf file.


This lab will be performed on the AIX machine. Estimated Time: 1 hour.

Part One: Creating a Self-Signed Certificate

The IKEYMAN utility provides for the management of digital certificates. In this exerciseyou will first create a database to store the certificates and then generate a certificate.


2000/07/31 10:16:08 IBM WebSphere Workshop - Lab Exercise Enabling SSL3_5.lwpPage 1 of 8

__1. Run the IKEYMAN program by opening a terminal window. Enter the followingcommands:

export JAVA_HOME=/usr/jdk_baseikeyman

IKEYMAN is a Java based program. If it fails to initialize, then there is a problem with theconfiguration settings that run the JVM on your workstation.

__2. Click Key Database File in the menu bar. Then click New.

__3. In the dialog box for creating a New Key Database File specify the following values:

Key Database Type: CMS Key Database FileFile Name: key.kdbLocation: <http_root>/ssl

NOTE: To locate the path type the following command: find / -name httpd



__4. Click OK.

__5. This will bring up a pop up window where you need to specify a password that will beused to protect the key database file:

___ Enter was1edu in the password field and the confirm password field. ___ Select the Stash the password to a file check box. ___ Click OK.

An informational message will appear indicating that the password was encrypted andhas been saved to a file. Click OK.

The IKEYMAN program now displays the content of the key.kdb file.

__6. The next step is to create a certificate. Click Create --> New Self-Signed Certificate...from the action bar.

__7. Specify the following values for the new certificate:

Key Label: wascert Common Name: <Fully qualified hostname> (this may be filled in)Organization: WAS Architects

You may specify the optional values if you prefer. However, leave the default values thesame. Click OK.



A new certificate based on the information that you provided will be created. In the keydatabase section an entry for this certificate will appear. Select it and click the View/Editbutton to see the certificate properties. Close the properties window and then exitIKEYMAN.

Part Two: Defining a Virtual Host and Configuring for SSL

To define a virtual host the configuration file for the IBM HTTP Server will be modified.

__1. Change directories to your <http_root>/libexec folder. Type ls to display the files. If youare running the 128-bit version of IBM HTTP Server (US and Canada only), verify that youhave a file mod_ibm_ssl_128.so listed as one of the files. If you are running the 56-bitversion of IBM HTTP Server, verify that you have a mod_ibm_ssl_56.so listed as one ofthe files.

__2. Use a text editor to open the httpd.conf file. It is located in the <http_root>/confdirectory.



__3. Search for the entry “LoadModule” and add one of the following lines as the first entry inthe list:

LoadModule ibm_ssl_module libexec/mod_ibm_ssl_128.so (for the 128-bit HTTP Server) orLoadModule ibm_ssl_module libexec/mod_ibm_ssl_56.so (for the 56-bit HTTP Server)

This instructs the Web server to load the SSL security module. The module, mod_ibm_ssl_128.so, is included with the export version of the IBM HTTP Web server.The 128-bit encryption module is available for use in US and Canada only.

__4. Search for the entry “AddModule” and add the following line at the top of the AddModulelist: AddModule mod_ibm_ssl.c

__5. Add the following directives after the section that defines the modules to be loaded:

Listen [HOST_NAME]:443<VirtualHost [HOST_NAME]:443>ServerAdmin [your email address]ServerName [Fully Qualified Hostname]ErrorLog logs/Big3-error.logTransferLog logs/Big3-access.logSSLEnableSSLClientAuth noneSSLServerCert wascert</VirtualHost>

Replace the tag [HOST_NAME] with the short name of your machine.

Provide appropriate values for the [your email address] and the [Fully QualifiedHostname] tags.

The SSLEnable directive tells the webserver to use SSL Encryption when requests aremade to this virtual host.

SSLClientAuth is set to none. This indicates that the browser will not have a client sidecertificate. SSLServerCert specifies the name of the certificate to use.

__6. These settings will differ for each virtual host. However, there are three other SSLsettings which have a global scope. These include the directives for the CertificateDatabase to use and the timeouts for SSL 2.0 and SSL 3.0. The following three linesneed to be added after the definition of the virtual host.

Keyfile <http_root>/ssl/key.kdbSSLV2Timeout 100SSLV3Timeout 1000



__7. Find the following section:

Port 80

# Listen: The Listen directive is required only if the server will# be listening on more than 1 port.

#Listen 80

__8. Delete the “#” from the #Listen 80 command line.

__9. Save the changes to httpd.conf and close the file.

__10. Change directories to <http_root>/bin and stop the IBM HTTP server by typing thefollowing command: ./apachectl stop.

__11. Restart the IBM HTTP Server: ./apachectl start. Test the virtual host and SSLconfiguration changes by accessing https://<machine name> with your browser. Beforethe default page appears, a series of screens are displayed informing you that a securedsite is being accessed. Information about the certificate can be displayed by clicking theMore Info... button.

__12. Stop the Big3 Server.



__13. To serve the Big3 application by using SSL, make the following changes from theadministrative console:

__A. From the Topology view select the entry for default_host. The properties will be displayed in the content pane.

__B. Click on the Advanced Tab. In the section on Aliases, add the entries for the Fully Qualified Name (FQN), IP address and the shortname. The FQN is the machine name followed by the domain name. The shortname is the machine name. After the changes are made, the entries should be as follows:

<Fully Qualified HostName>:443 <ip-address>:443 <shortname>:443

__C. Click Apply. Restart the Big3 server.

__14. Test the SSL setup by accessing:https://<Fully_Qualified_HostName>/Big3/index.html.

Before the page is loaded, you will see a message indicating that a secured site is beingaccessed and that the browser does not recognize the Certificate Authority that issuedthe server certificate. Go through the steps of accepting the certificate. When presentedwith options for the duration the certficate should be valid, select the option for a singlesession.

__15. You will receive a logon challenge window. Login in as wasedu.

An “open” padlock displayed in the status bar indicates that the page being viewed is notsecured.

After the certficate is accepted, the padlock image should change as follows:

Note: If you get a “file not found” error, wait a few moments and reload the browser.

Known Problem: When you initiate an HTTP request to a WebSphere ApplicationServer Web by using Secure Socket Layer (SSL), and if the Web server is configuredto perform mutually, it may not be able to retrieve the client certificate from a servlet.

Also, for the same reason, when you use the WebSphere Application Server's security infrastructure, you will not be able to use the certificate challenge type that is under the



Application Security attributes. This means that Certificate is not a supported challenge type.(From: http://www.ibm.com/software/webservers/appserv/doc/v30/relnotes.html)

Summary

In this lab you created a self-signed certificate, defined a virtual host in the IBM HTTP, andconfigured the server for SSL encryption.

END OF EXERCISE




Accessing Secured Applications


In this exercise you will access a secured enterprise bean from a Java application that resideson the client.


After this lab you should be able to:

� Create the configuration file that is to be used by the Java application.

� Specify the appropriate command line parameters while starting the Java application.

� Understand the impact of the Abstract Windowing Toolkit (AWT) implementation and makethe necessary code changes.


Part One and Part Two are performed on the NT machine. Part Three is performed on theAIX machine. Estimated Time: 15 minutes.

Part One: Creating the Configuration File

__1. Copy <as_root>\properties\sas.client.props to<as_root>\properties\javaclient.props.

__2. Use a WordPad or NotePad to verify the following lines are present and correct:

com.ibm.CORBA.securityEnabled=truecom.ibm.CORBA.loginSource=prompt

Save the file.


2000/08/17 08:24:41 IBM WebSphere Workshop - Lab Exercise Accessing Secured Apps3_5.lwpPage 1 of 3

Part Two: Starting the Java Application from the Command Line

__1. The Big3Client is located in the C:\big3\ directory. Open an MS-DOS window and changeto that directory.

__2. At the command prompt type runClient.bat. The command should fail.

__3. When security is enabled all EJB communication is SSL encrypted. You must add theSSL package to the class path of the client for this functionality to work correctly.

Edit the GetClientCasspath.bat file and add the following entry as the last “set CLIENT_CP=” entry:

set CLIENT_CP=%CLIENT_CP%;%WAS_HOME%\lib\sslight.jar

__4. Run compile.bat from an MS-DOS command window while you are in the big3 directoryto compile Main.java.

__5. In an MS-DOS command window, type runClient 12345 (this is the policynumber) 45678 (this is the claim number) 7899 (this is theamount) <AIX_machine_name> and press Enter.

When you start the command, the Java client uses the Java Naming and Directory Interfaces(JNDI) protocol to locate the home interface of the bean. Once the handle to the interfaceis obtained, the bean class is instantiated. After the object has been created, methodscan be started on it as if the object was present locally on the machine.

Part Three: Backing Off Security on the AIX Machine

In this section, you will disable the security settings in the WebSphere.

__1. From the Tasks menu, start the Configure Global Security Settings wizard.

__2. Deselect the Enable Security check box.

__3. Click Finish to save the settings. You will see a confirmation message that indicatessuccess and also lets you know that the administrative server needs to be stopped andrestarted before the new security settings can take effect.

__4. Restart the Administrative server.



Definitions

Handle: An EJB object handle is a persistent reference to an EJB object. Handles allow you todisconnect from your EJB server, shut your application down, and later resume yourapplication while preserving the conversational state in the beans you have been workingwith.

Instantiate: In object-oriented programming, to represent a class abstraction with a concreteinstance of the class.

Summary

In this lab you created the configuration file that is to be used by the Java application, specifiedthe appropriate command line parameters while starting the Java application, and backed offsecurity.

END OF EXERCISE

