®

IBM Software Group

What’s New in WebSphere Security

WAS V6.1

© 2005 IBM Corporation

 IBM Software Group

Agenda

ƒ Security Enabled by Default and WebSphere Member Registry

ƒ SSL, KeyStore, Certificate, and Key Management Enhancements
ƒ Windows Single Sign-On (SSO) using the SPNEGO TAI
ƒ Fine-Grained Admin Security
ƒ Portlet URL Security
ƒ Security Integration Options

2
 IBM Software Group

WebSphere v6.1 Security Features (Enablement)

ƒ Security Enabled By Default
• Enabled during install and profile creation to protect administrative
resources.
– Option to disable.
• File-based repository used by default.
– Stores primary administrative identity and password as the initial
user.
– Specified during install/profile creation or security enablement (if not
enabled during install).
• Administrative security is split from application security enablement.
– Must have administrative security enabled before enabling
application security.
– Application security enables J2EE container authentication and
authorization.
– Administrative security protects other resources including Naming,
MBeans, System Applications, etc.
• LTPA keys, self-signed certificate, keystores, server default identity are all
generated automatically during profile creation.
3
 IBM Software Group

WebSphere v6.1 Security Features (Enablement)

ƒ Consumability Improvements
• Redesigned security console to improve usability.
• Security Configuration Wizard for simplifying enablement for new users.
• Security Configuration Report for showing security configuration
overview

4
 IBM Software Group

Security Enablement in Profile Tool

Enables administrative
security only (protects
System applications).
Application security
must still be enabled
post-install.

LTPA keys, self-signed

certificate, and key and trust
stores are automatically
created during profile creation.
Even when security is not
enabled here.

5
 IBM Software Group

Secure administration, applications, and infrastructure

Wizard simplifies Report displays security
security configuration configuration attributes
steps for first-time and settings in a table
users. format

Must enable
administrative
security before
application security
or Java 2 Security
can be enabled.

Configuration of
New Federated Repositories LTPA or SWAM
selection which allows multiple (deprecated).
File-Based and LDAP registries to
be searched.

6
 IBM Software Group

Virtual Member Manager - Federated Repositories

Configuration Single realm name for entire cell
even though multiple repositories
can be configured.

Automatically generated server identity is an LTPA

token protected identity for internal system calls.
This is the default selection in v6.1.

Must use this server ID and password

choice for mixed-version Cells due to
previous version requirements.
Password is optional though for v6.1.

List of File-based and

LDAP registries
configured. Database
Used to store Supports entry-level join of registry may be configured
attributes about multiple repositories. through scripting.
users that cannot be
stored in existing Supported entity types must
repositories. be configured before you
can write to this repository
via Manage Users/Groups.

7
 IBM Software Group

Agenda

ƒ Security Enabled by Default and WebSphere Member Registry

ƒ SSL, KeyStore, Certificate, and Key Management Enhancements
ƒ Windows Single Sign-On (SSO) using the SPNEGO TAI
ƒ Fine-Grained Admin Security
ƒ Portlet URL Security
ƒ Security Integration Options

8
 IBM Software Group

WebSphere v6.1 Security Features (Crypto)

ƒ SSL Configuration Management
• Dynamic SSL configuration updates (all outbound, CFW inbound)
• Pluggable key and trust manager support
• Support for CRL checking using PKIX trust manager
• Multiple SSL configuration selection types with precedence rules:
– Programmatic selection (thread-based)
– Dynamic outbound selection (outbound protocol, target host and port)
– Direct selection (for backwards compatibility)
– Scoped selection (centrally managed)

ƒ KeyStore and Certificate Management

• No longer shipping the dummy certificate
• Self-signed certificate created per profile (properties to define values).
• Advanced IKeyMan-like certificate management capabilities built into
AdminConsole via AdminTasks.
• WebSphere SSL socket factory removes system property requirements
for SOAP and URL connections
• More detailed error messages for SSL handshake failures

9
 IBM Software Group

WebSphere v6.1 Security Features (Crypto)

ƒ KeyStore and Certificate Management (server-side)
• Keystores can be remotely managed
• Federation of Base AppServer exchanges signer with Deployment Manager
• Common TrustStore used by default in Cell
• Java-based CMS keystore provider used to automate creation of CMS
keystores (w/password stash) for WebServer plugins.
• Expiration monitoring with notification (email and logs) and auto-replacement
of expiring self-signed certificates (based on threshold)
• SSL and KeyStore configurations hierarchically scoped to a WAS
management resource (e.g., endpoint, server, cluster, node, nodegroup, cell)

ƒ KeyStore and Certificate Management (client-side)

• Signer exchange prompt for easy exchange (browser-like, can disable prompt)
• RetrieveSigners script for downloading and uploading (protected) signers
• By default, same self-signed certificate as server of the same profile
• New SSL configuration properties file, ssl.client.props, supports multiple SSL
configurations
• Same SSL configuration support as server-side, including pluggable trust/key
managers

10
 IBM Software Group

WebSphere v6.1 Security Features (Crypto)

ƒ Key Lifecycle Management
• Generic key and key pair generator interfaces
• Automatically deletes old keys when new key generated and
maximum number of managed keys reached
• LTPA implements key set and key set groups to manage auto-
generation of LTPA keys
• Keys stored in keystores (can be hardware keystore)

11
 IBM Software Group

SSL, KeyStore, and Certificate Management

Cell-scoped
configurations.

Show
topology view
for
finer-grained
Periodic task configuration
monitoring for scopes.
certificate
expiration.

Careful: Dynamically
updates the runtime
after changes saved
and sync'd.

12
 IBM Software Group

SSL Configurations Scoped by Topology

Node association
overrides Cell
association. Everything
below the Node, inherits
this SSL configuration.
Inbound SSL
configuations.

Specific endpoints for

"server1". Note: No
associations currently
made here, inherits
from Node.
Outbound SSL
configuations.

Outbound endpoints
are configured by
"protocol name".

13
 IBM Software Group

Panel: Keystore Collection

Select two
keystores and
exchange signers.

Default keystores
are managed in the
configuration
repository and
synchronized to
Nodes.

14
 IBM Software Group

Exchange Signers

Extract personal
certificate and
move over to the
other keystore as a
signer.

15
 IBM Software Group

KeyStore (Managed on the Node)

Certificate
Keystore management
type. links.

Remotely managed
indicates the keystore
physically resides on a
Hardware devices used Node. An MBean request
for acceleration would is sent for the certificate
benefit from immediate management updates.
initialization.
16
 IBM Software Group

Personal Certificate Collection

ƒ Same IKeyMan-like function except for the advanced “Replace” function. This will allow the
selection of certificate to replace with a new one. It replaces all old signers. This is the same
function used by the certificate expiration monitor to replace an expiring certificate.

17
 IBM Software Group

Signer Certificate Collection

18
 IBM Software Group

Panel: Scoped SSL Configuration

19
 IBM Software Group

WebServer Plugin SSL Configuration

20
 IBM Software Group

Key Lifecycle Management – Active Key History

ƒ This shows the current key aliases that are tracked by a

specific KeySet.
ƒ The aliases can be generated dynamically (when keys are
generated dynamically) or they can be references to already
existing aliases in the KeyStore.
21
 IBM Software Group

LTPA Use of KeySetGroup for Key Management

22
 IBM Software Group

z/OS Specific Changes

ƒ CSIv2 implementation for IIOP security now mostly common-

code with distributed (Java-based).
ƒ Support for HW Crypto exploitation for LTPA and web services
security for soft non hw managed keys.
ƒ Enhanced Sync-to-thread to move the enablement decision
into SAF.
ƒ Added support to optionally utilized the new RACF mixed case
password.
ƒ All but the LSD daemon SSL has moved to JSSE.

23
 IBM Software Group

Agenda

ƒ Security Enabled by Default and WebSphere Member Registry

ƒ SSL, KeyStore, Certificate, and Key Management Enhancements
ƒ Windows Single Sign-On (SSO) using the SPNEGO TAI
ƒ Fine-Grained Admin Security
ƒ Portlet URL Security
ƒ Security Integration Options

24
 IBM Software Group

Single sign-on (SSO) for HTTP using SPNEGO TAI

ƒ WebSphere Application Server provides a trust association interceptor (TAI) that
uses the Simple and Protected GSS-API Negotiation Mechanism (SPNEGO) to
securely negotiate and authenticate HTTP requests for protected resources in
WebSphere Application Server.

ƒ With SPNEGO TAI support, after a user login to the MS domain controller, the Web
browser client does not have to provide a user ID and password again to access
protected resources in WebSphere Application Server.

ƒ A JAAS custom login module is used to map the client Kerberos principal name to
the WebSphere user name.

ƒ Support for all User Registries and platforms that are supported by WebSphere
Application Server.

ƒ Support web browsers:

 Microsoft Internet Explorer V6.0 SP1
 Mozilla V1.7.8
 Firefox V1.5

ƒ Support one or more Microsoft (MS) domain controllers within the same forest.

25
 IBM Software Group

TAI Basics (A Brief Digression)

ƒ Normal WAS Authentication Process

1. User Authenticates with WAS
2. WAS Issues Credentials to User
3. Application Request(s) are Processed

ƒ WAS Authentication Process with TAI

1. User Authenticates with Third Party Security Server
2. Request Flows to WAS (with Security Server credentials)
3. Custom TAI Authenticates Request to ensure it is trusted
4. WAS Issues Credentials
5. Application Request(s) are Processed Based

26
 IBM Software Group

Challenge-responses process between web browser and SPNEGO TAI

Active Directory Kerberos KDC WebSphere

Registry

Windows 2000/3
Server

3. Request Ticket Granting Ticket (AS_REQ)

4. Get Ticket Granting Ticket (AS_REP)
5. Request Service Ticket (TGS_REQ)
6. Get Service Ticket (TGS_REP)

8. Get userid from SPNEGO token

9. Validate user with Registry
10. Create LTPA Token
1. HTTP/Post/Get/Web-Service

2. HTTP 401 Authenticate/Negotiate

WebSphere
Browser/.NET Client 7. HTTP/Post/Get/Web-Service + Authorization SPNEGO Token SPNEGO TAI
Application Server
11. HTTP 200, Content, LTPA Token

Windows Client Server Machine

Machine

27
 IBM Software Group

SPNEGO TAI Configuration in WebSphere Application Server

ƒ Panel: Enable Trust Association

28
 IBM Software Group

SPNEGO TAI Configuration in WebSphere Application Server

ƒ Enable SPNEGO TAI through JVM system property

Application servers > server1 > Process Definition > Java Virtual
Machine

-Dcom.ibm.ws.security.spnego.isEnabled=true

29
 IBM Software Group

Agenda

ƒ Security Enabled by Default and WebSphere Member Registry

ƒ SSL, KeyStore, Certificate, and Key Management Enhancements
ƒ Windows Single Sign-On (SSO) using the SPNEGO TAI
ƒ Fine-Grained Admin Security
ƒ Portlet URL Security
ƒ Security Integration Options

30
 IBM Software Group

Fine-Grained Admin Access Control

ƒ Configurable by scripting only.
ƒ Authorization groups setup to group resources.
ƒ Group Resources
Cell, Node, ServerCluster, Server, Application, or NodeGroup.
Cell authorization group available by default
ƒ Provides backwards compatibility.
ƒ A resource can only belong to a single authorization group.
ƒ Users/groups assigned to roles and authorization groups.
ƒ Restrictions
WebSphere Application Servers lower than V6.1 cannot enforce
fine-grained administrative security
SIB resources cannot be managed as part of fine-grained
administration

31
 IBM Software Group

Scripting Operations to Setup Fine-Grained Admin Authz

ƒ Create a new authorization group
ƒ Deleting an authorization group
ƒ Add resources to an authorization group
ƒ Remove resources from an authorization group
ƒ Add user IDs to roles in an authorization group
ƒ Add group IDs to roles in an authorization group
ƒ Remove user IDs from roles in an authorization group
ƒ Remove group IDs from roles in an authorization group

32
 IBM Software Group

New Deployer Role

ƒ The Deployer role is for users who need to manage applications
The Deployer role is a subset of the Configurator and Operator roles
Only provides the ability to manage applications
ƒ Users within the Deployer role can configure and perform runtime
operations on applications
No abilities on other resources (server, node, cluster)
ƒ This role is only available for wsadmin users.

Administrator

Configurator Deployer Operator

Monitor
33
 IBM Software Group

Deployer Role
Operation Required Role(s)

Install Application Cell Configurator, target-deployer

Uninstall Application Cell Configurator, application deployer

List Applications Cell monitor, application monitor

Edit, update and redeploy application Cell configurator, application deployer

Export application Cell monitor, application monitor

Start—stop application Cell operator, applcation deployer

34
 IBM Software Group

New AdminstrativeSecurityManager Role

ƒ AdministrativeSecurityManager
Separates fine-grained administrative security and application
administration
When fine-grained administrative security is used, only users granted this
role can manage the authorization groups
Only users granted this role can map users to administrative roles
ƒ Note that the administrator role does not correlate to the
adminsecuritymanager role
By default, the serverId(SystemId) is assigned to this role in the cell level
authorization table

35
 IBM Software Group

Agenda

ƒ Security Enabled by Default and WebSphere Member Registry

ƒ SSL, KeyStore, Certificate, and Key Management Enhancements
ƒ Windows Single Sign-On (SSO) using the SPNEGO TAI
ƒ Fine-Grained Admin Security
ƒ Portlet URL Security
ƒ Security Integration Options

36
 IBM Software Group

Portlet URL security

ƒ WAS 6.1 has an embedded JSR168 Portlet Container.

ƒ One can directly request a portlet through a URL to display its
contents without portal aggregation.
ƒ Similar to servlets one can invoke a portlet by its context root
with the URL mapping /<portlet-name> that is created for each
portlet.
ƒ Portlets can be protected just like servlets when accessed
using the URL.
ƒ The information in the portlet.xml like the user-data-constraint
and security-role-ref will be combined with the information in
the web.xml for that portlet which can be explicitly defined or
implied through an url-pattern.

37
 IBM Software Group

Agenda

ƒ Security Enabled by Default and WebSphere Member Registry

ƒ SSL, KeyStore, Certificate, and Key Management Enhancements
ƒ Windows Single Sign-On (SSO) using the SPNEGO TAI
ƒ Fine-Grained Admin Security
ƒ Portlet URL Security
ƒ Security Integration Options

38
 IBM Software Group

Security Integration Options (1/4)

ƒ TAM Authentication Integration with WAS

Web SSO integration
ƒ WebSEAL/TAM authenticates web browser user and passes that
information on to WAS
– Leverages standard WAS TAI function
– WAS ships with WebSEAL/TAM TAI
– Configure via admin console, under LTPA section
ƒ Access Manager can directly issue LTPA tokens - deprecated
– Have to export WAS LTPA encryption key to TAM and keep two copies in
sync

39
 IBM Software Group

Security Integration Options (2/4)

ƒ Trusted Association
WAS can be told to "trust" web proxy authentication systems via a
Trusted Association
ƒ Write custom plug-in Java code that WAS calls when identifying user
web request. WAS will trust your code to identify user.
ƒ Can provide to WAS
– Userid
– Group membership information
– Optional attributes to place in Subject. E.g., any serializable Java object.
ƒ WAS will still obtain some information from registry (LDAP or custom)
ƒ Only works with web based authentication. Won't help with other SSO
systems
ƒ Login Module
Customize authentication process for web and IIOP
Similar to TAI

40
 IBM Software Group

Security Integration Options (3/4)

ƒ Custom Registry
Customized registry access
ƒ JACC = Java Authorization Contract for Containers
Customized authorization
When WAS needs to make an authorization decision, it will ask JACC
provider
ƒ Direct LTPA Integration
Domino has support for recognizing LTPA tokens
Multiple WAS cells can communicate securely if
ƒ They share common LTPA encryption keys - export LTPA keys using
Security Center and import into peer domains
ƒ Share a common registry
ƒ Share compatible SSL keyrings – E.g., the caller has to have the
signing certificate that corresponds to the server being called. Just the
usual SSL stuff.

41
 IBM Software Group

Security Integration Options (4/4)

ƒ Which Option Should I Use?

Use the one with the closest semantic match to your goal
ƒ Direct LTPA integration should be used with Domino, not TAM
ƒ TAI integration preferred with TAM/WebSEAL
ƒ TAIs and login modules are for recognizing an existing
authentication
ƒ Allow for dynamic information in Subject during login process
ƒ Doesn’t even require that same data be in registry
ƒ CURs are for getting data from a non-standard source statically
ƒ Tend to break interoperability since generally require common registry
ƒ Triggers need for custom registry in Portal as well
ƒ Prefer TAIs and login modules over CURs when possible
ƒ JACC – probably shouldn’t use at all
42
 IBM Software Group

Backup

43
 IBM Software Group

Migration/Mixed Version/Mixed Platform Issues

ƒ Migration will preserve keystores in entirety. If v6.02 is migrated to v6.1 and it
used the Dummy certificates, these will be preserved. It’s difficult to determine
if some customization has occurred to all or part of an SSL configuration and
safer to migration this way. These can more easily be converted to self-signed
certificates in the new certificate management panels.
ƒ Migrating the existing keystores allows a mixed version Cell to work properly as
back-level servers do not have the advanced functions to handle signer
exchange. Default certificates can more easily be replaced using the new
certificate management panels.
ƒ Back-level clients will have difficulty communicating with a v6.1 server (using
self-signed certs). The client will need to be reconfigured to use the v6.1
key/trust stores or add the necessary signers using IKeyMan.
ƒ When Dmgr is z/OS (using RACF keystores) and Node is distributed (using
self-signed cert inside PKCS12 keystores), a manual signer exchange should
occur prior to performing an addNode.
ƒ When performing an addNode from a v6.02 Node to a v6.1 Dmgr, the v6.02
Node needs to exchange signers with the v6.1 Dmgr prior to being able to
federate.
ƒ Migration disables “Web inbound attribute propagation” whenever a v5.1 or
prior Node is part of a mixed-version Cell due to problems interoperating with
LtpaToken2 (new version of LtpaToken introduced in v5.1.1).

44
 IBM Software Group

SPNEGO TAI configuration elements

45
 IBM Software Group

SPNEGO TAI Configuration for WebSphere Application Server

ƒ Create a Kerberos key tab file from the Active Directory (AD) machine
 Create a user name w2003secdev in AD and check the option Use DES
encryptions types for this account.
 Use MS setspn tool to map the user name to the SPN format HTTP/<hostname>
ƒ C:\MS SDK>setspn -a HTTP/w2003secdev.austin.ibm.com w2003secdev
 Use MS ktpass tool to generate the Kerberos keytab file krb5.keytab for the SPN
ƒ ktpass -out c:\temp\krb5.keytab -princ
HTTP/w2003secdev.austin.ibm.com@WSSEC.AUSTIN.IBM.COM
-mapUser w2003secdev -mapOp set -pass security -crypto DES-CBC-MD5
+DesOnly
ƒ Copy the krb5.keytab file to the WebSphere Application Server machine at the
location which specify in the Kerberos configuration file (krb5.ini or
krb5.conf).
ƒ Note: The Windows 2003 server ktpass support both DES and RC4-HMAC

46
 IBM Software Group

Configure MS IE browser to use SPNEGO authentication

Make sure the client machine is part of a domain for which SSO has been defined. In the
following example, the machine w2003secdev.austin.ibm.com is a member of the domain
controller wssec.austin.ibm.com. Log on to the Windows Desktop with a user name from the
domain.

1. Open the browser, go to menu bar Tools -> Internet Options

2. Select the Security tab.
3. Select Local intranet icon.
4. Click Sites.
5. Click Advanced.
6. Add the URL for the host name that SSO should be enabled for, to the list. For example:
http://w2003secdev.austin.ibm.com
7. Click OK.
8. Click OK.
9. Select the Advanced tab.
10. Scroll down to security section and ensure that Enable integrated Windows
Authentication(requires restart) is checked.
11. Close the browser.
12. Start the browser.

47
 IBM Software Group

Configure Mozilla or FireFox browser to use SPNEGO authentication

1. Open the browser.

2. At the address field, type about:config
3. In the filter, type network.n

4. Double click on network.negotiate-auth.trusted-uris. This preference lists the

sites that are permitted to engage in SPNEGO Authentication with the browser
5. Enter a comma delimited list of trusted domains or URLs. For example:
http://w2003secdev.austin.ibm.com
6. Close the browser.
7. Start the browser.

48
 IBM Software Group

Scripting Operations to Setup Fine-Grained Admin Authz

ƒ Create a new authorization group: $AdminTask createAuthorizationGroup {-
authorizationGroupName authGroup1}
ƒ Deleting an authorization group: $AdminTask deleteAuthorizationGroup {-
authorizationGroupName groupName}
ƒ Add resources to an authorization group: $AdminTask
addResourceToAuthorizationGroup {-authorizationGroupName groupName -
resourceName Application=app1}
ƒ Remove resources from an authorization group: $AdminTask
removeResourceFromAuthorizationGroup {-authorizationGroupName groupName -
resourceName Application=app1}
ƒ Add user IDs to roles in an authorization group: $AdminTask
mapUsersToAdminRole {-authorizationGroupName groupName -roleName
administrator -userids user1}
ƒ Add group IDs to roles in an authorization group: $AdminTask
mapGroupsToAdminRole {-authorizationGroupName groupName -roleName
administrator -groupids group1}
ƒ Remove user IDs from roles in an authorization group: $AdminTask
removeUsersFromAdminRole {-authorizationGroupName groupName -roleName
administrator -userids user1}
ƒ Remove group IDs from roles in an authorization group: $AdminTask
removeGroupsFromAdminRole {-authorizationGroupName groupName -roleName
administrator -groupids group1}
49
 IBM Software Group

Portlet URL Security Example

Portlet relevant Security Constraints in web.xml

---------------------------------------------------------------
<security-constraint id="SecurityConstraint_1">
<web-resource-collection id="WebResourceCollection_1">
<web-resource-name>Protected Area</web-resource-name>
<url-pattern>/MyPortlet1/*</url-pattern>
<url-pattern>/MyPortlet2/*</url-pattern>
</web-resource-collection>
<auth-constraint id="AuthConstraint_1">
<role-name>Employee</role-name>
</auth-constraint>
</security-constraint>

Security Constraints in Portlet.xml

---------------------------------------------
<security-constraint>
<display-name>Secure Portlets</display-name>
<portlet-collection>
<portlet-name>MyPortlet1</portlet-name>
<portlet-name>MyPortlet3</portlet-name>
</portlet-collection>
<user-data-constraint>
<transport-guarantee>CONFIDENTIAL</transport-guarantee>
</user-data-constraint>
</security-constraint>

50
 IBM Software Group

Portlet URL Protection based on above constraints

URL Transportation User Authorization

Protection Authentication

MyPortlet1/* HTTPS Yes Yes

(Employee)
MyPortlet2/* None Yes Yes
(Employee)
MyPortlet3/* HTTPS None None

MyPortlet4/* None None None

51