© 2015 IBM Corporation

AAI-1169 What new in WebSphere Application Server Security and Cloud Readiness

Bill O'Donnell

STSM – AIM/WebSphere Security Compliance Officer and WebSphere Foundation Security Architect

IBM – WebSphere Development

2

About the Speaker

Bill O'Donnell

– My email is bill.odonnell@us.ibm.com

– AIM/WebSphere Security Compliance Officer

– WebSphere Foundation Security Architect

– Responsible for:

• Security Architecture and Design for WebSphere Portfolio

• Security Architect for WebSphere Application Server

• Insure Security Compliance for SaaS, PaaS, and on-prem Software solutions.

• Product Security Incident Response Team (PSIRT) for WebSphere and AIM brand

• Product Secure Engineering for WebSphere and AIM brand

– See my website at http://www.ibm.com/developerworks/websphere/zones/was/security/

3

What are we going to talk about?

Recap on Security Feature WAS 6.1, WAS 7.0. WAS

8.0, and WAS 8.5.

WebSphere Brand received the Open Trusted

Technology Provider™ Standard (O-TTPS)

Accreditation

What new for Liberty Profile 8.5.5.0

What new for WebSphere Application Server for

Liberty Profile and Full Profile after 8.5.5.4

WebSphere Application Server Security statement of

direction

Recap on Security Features WAS 6.1, WAS 7.0, WAS 8.0 and WAS 8.5

WAS 6.1 Security Highlights

• Admin Security enabled by default

• Auto generate of the Server ID removing need for server

userID/Pass

• Simple Key and Certificate Management

– Supports the full life cycle Key and Certificate Management

– Key management tool through console and WAS scripting

– Easier to configure SSL

– Certificate Monitoring for expired Certificates

• SPNEGO supporting SSO from Microsoft Desk top into WAS

• FIPS 140-2 compliant

5

WAS 6.1 Web Services Security Highlights

• Secure JAX-WS web service application (Web Services Feature pack)

• Support WS-Security 1.1 (signature confirmation and encrypted headers)

• WS-SecureConversation

• Username token profile 1.1

• X509Token profile 1.1

• Support LTPA token type

• Secure web service application using policy set

• Secure web service application using WSSAPI

6

WAS 7.0 Security Highlights

• WebSphere Security Domain

– The ability to have multiple security configurations within a cell

– Administration and Application Security separation

– Application Security configuration can be map to server or cluster

• Enhancement in Kerberos

– Integrated SPNEGO Support

– Server to Server Authentication and Propagation

– Connect to DB2 using Kerberos

• Enhancements in Key and Certificate Management

– Certificate Chaining

– Easy way to renew Certificates through Console or Scripting

– During profile create to personalize the certificate – DN, Expiration date, password

– Ability to restore a deleted Certificate

7

WAS 7.0 Web Services Security Highlights

• Included the Web Services Feature Pack from WAS 6.1

• Secure JAX-WS 2.1 web service application

• Basic security profile (WS-I BSP) 1.0

• WS-Trust 1.3

• WS-SecureConversation 1.3

• Kerberos token profile 1.1

• WS-SecurityPolicy 1.2

8

WAS 8.0 Security Highlights

• Web Services Security Enhancements

• JAX-WS 2.2

• Web Service Security: SAML token profile 1.1

• SHA256 XML signature algorithm

• EE Security Enhancements

– EJB imbedded container supporting easy way of developing and testing security flows

– Servlet 3.0 security annotations to map Security Constraints in the Java program vs using web.xml

• Security Hardening

– SSL now required by default for EJB via CSIv2 Security

– HTTPOnly enabled by Default

– Default Certificate key Length now 2048

• Federated Repository (VMM) Enhancements

– Usability improvements in the Admin Console

– Remove Security Domain restriction

– Command line to change file base registry password

9

WAS Full Profile 8.5.0.0 Security Highlights

• SAML Web SSO Post Binding Profile back ported to 7.0.0.23, 8.0.0.4.

• OAuth Support back ported to 7.0.0.25, 8.0.0.5, and 8.5.0.1 and WAS

Liberty Profile 8.5.0.2 WAS

• TLS 1.2 and FIPS 800-131a back ported to 8.0.0.3 and 7.0.0.23

10

Liberty Profile V8.5.0.0 security

• Basic, Form, Cert login

• EE Programmatic APIsisUserInRole, getUserPrincipal

getRemoteUser, authenticate

login, logout

• RunAsRole

• Transport layer security (SSL)

• RegistryBasic Registry

LDAP Registry (SSL, failOver, referrals)

SAF

• WebSphere Authorization • SAF Authorization

• Basic Single SignOn – LTPA

• Authentication Aliases• Session security• JAAS• TAI• Relevant Public APIs (wsspi, websphere packages)• JMX security

RestConnector security

MBean security

Only one administrator role

• Simple password encoding

11

Configuring Security Features

• appSecurity-1.0

– Includes all the security services (authentication, registry, authorization) and web specific security code

• zosSecurity-1.0

– Includes the SAF registry and authorization code

• ssl-1.0

– Includes the SSL specific code

12

For more information

• See our website at http://www.ibm.com/developerworks/websphere/zones/was/security/

for more information on

– WAS 61, WAS7, and WAS8

– Security Hardening

– FAQ

– How to...

13

WebSphere Brand received the Open Trusted Technology Provider™ Standard(O-TTPS) Accreditation

http://ottps-accred.opengroup.org/accreditation-register

Growing market demands for secure supply chain assurance

• IBM receives increasing customer requests for 3rd party scans as evidence of product/supply chain assurance.

• US legislation with cybersecurity requirements targeting product & supply chain assurance

• Cybersecurity Act of 2012

• National Defense Authorization Act of 2013

• Examples of supply chain focus in US Federal:

• NASA RFP lists O-TTPS (*) as an example of "standards/certifications held by the manufacturer that mitigate, reduce or eliminate supply chain and related security issues“

• NISP SP 800-161 draws on O-TTPS to integrate supply chain risk management practices into federal agencies

• As SP 800-161 and the other policies roll out, O-TTPS accreditation will become standard fare for all levels of risk as it pertains to COTS products in US Federal

15

Source: http://csrc.nist.gov/publications/drafts/800-161/sp800_161_draft.pdf

(*) O-TTPS: Open Trusted Technology Provider Standard

Open Trusted Technology Provider™ Standard

(O-TTPS) Accreditation Program

The Standard/Snapshot (released Jan 2014) – a set of prescriptive

requirements and recommendations for organizational best practices

Apply across product life cycle. Some highly correlated to threats of taint and

counterfeit - others more foundational but considered essential.

2 areas of requirements – that often overlap depending on product and

provider:

Technology Development mostly under the provider’s in-house supervision

Supply Chain activities mostly where provider interacts with third parties who

contribute their piece in the product’s life cycle

SourcingDesign Sustainment Disposal

Technology

DevelopmentSupply Chain

DistributionFulfillmentBuild

16

17

IBM Secure Engineering Initiative is built on the view that Security

is a shared responsibility of the entire development organization.

Programming

team

Support

team

Design

team

Test

team

Awareness and Education

All job roles need an understanding of the concepts and the implications of Security in Development

Project Planning Project/Release Managers need to include Secure Engineering in Project Planning activities

Risk Assessment and Threat Modeling

Architects and Designers need to review the security characteristics of existing software and document a Threat Model for new software

Security Requirements

Architects and Designers need to ensure that best practices for session handling, information protection, etc. are included in Design Specifications, Use Cases and Security Test Plans

Secure Coding Developers need to ensure that coding and configuration techniques are appropriate

Security Testing Test Teams need to learn about security testing and perform Security Testing using AppScan, with appropriate test plan and policy

Security Documentation

Information Developers need to ensure that all offerings include appropriate Security Documentation

Security Incident Response

Support Teams must participate in Security Incident Response Process

Management

team

What new for Liberty Profile 8.5.5.0

Summary of Security Features

19

Feature Introduced Description

appSecurity-1.0 8.5.0.0 All the security services (authentication, registry, authorization) and web specific security code

zosSecurity-1.0 8.5.0.0 z/OS SAF registry and authorization code

ssl-1.0 8.5.0.0 SSL specific code

appSecurity-2.0 8.5.5.0 All the security services (authentication and authorization) and Federation of User Registry

ldapRegistry-3.0 8.5.5.0 LDAP User Registry

OAUTH-2.0 8.5.5.0 OAUTH 2.0 support

<myCusReg> 8.5.5.0 Custom User Registry is implemented as a feature

appSecurity-2.0

• The new version appSecurity-2.0 is designed to supersedes the older version

appSecurity-1.0

• appSecurity-2.0 is designed to be more lightweight because it does include support

for the LDAP user registry and does not automatically include the servlet-3.0 feature.

• Recommend using the new version instead, and add any required features as

necessary. For example, update your server.xml as follows:

<featureManager>

<!-- Don't use superseded version -->

<!-- feature>appSecurity-1.0</feature-->

<feature>appSecurity-2.0</feature>

<!-- Add servlet-3.0 if you want to secure web applications -->

<feature>servlet-3.0</feature>

</featureManager>

20

21

2

1

EJB Security

Liberty 8.5.5.0 introduce EJB Lite 3.1

– Designed to control who can access your EJBs, either at the bean level or at the

method level

– Control the identity your EJB will use when it makes calls, either at the bean level

or at the method level

– Web profiles version of EJB is supported; Full EJB and remote look-up are not

supported

EJB Security

– Securing your EJBs is critical to ensure only authorized users can

perform certain actions in your environment

How to use this feature?

– Add the features appSecurity-2.0 and ejblite-3.1 to secure your EJBs

– Specify security elements in your application's deployment descriptor

ejb-jar.xml or the IBM extensions file ibm-ejb-jar-ext.xml or use

annotations

22

2

2

Custom User Registry

Designed to allows for a customised User registry of users and groups in the Liberty profile for authentication.

Designed to support is mostly the same as in the full profile WebSphere.

Requires the Custom User Registry to be implemented as a Feature

Configured in server.xml as

<featureManager>

<feature>appSecurity-2.0</feature>

<feature>usr:myCustomTAI-1.0</feature>

</featureManager>

Custom User Registry difference between Full profile and Liberty

• Liberty Custom User Registry (CUR) is designed to be implemented as a feature

• Two additional Method in the CUR

‒ The activate method - When the server starts or when a feature is added to the configdynamically, the user feature is designed to be detected by the feature manager and the bundles are installed into the OSGi framework, activated/started, and the activate() method will be called.

‒ The deactivate method will be called when your feature is being deactivated

publish/features/<myFeature>.mf file must be contained in your jar file For example

Subsystem-ManifestVersion: 1

Subsystem-SymbolicName: customRegistrySample-1.0;visibility:=public

Subsystem-Version: 1.0.0

Subsystem-Content: com.ibm.websphere.security; version="[1,1.0.100)",

com.ibm.ws.security.registry.custom.sample; version="[1,1.0.100)"

Subsystem-Type: com.ibm.websphere.feature

IBM-Feature-Version: 2

For more information, please see the Knowledge Center (formally Info Center)

23

Liberty Trust Association Interceptor (TAI)

• By design, the TAI can be a feature or non feature. Recommendation is to use feature

• Similar to CUR, there two additional Method in the CUR

‒ The activate method - When the server starts or when a feature is added to the configdynamically, the user feature is designed to be detected by the feature manager and the bundles are installed into the OSGi framework, activated/started, and the activate() method will be called.

‒ The deactivate method will be called when your feature is being deactivated

publish/features/<myFeature>.mf file must be contained in your jar file For exampleSubsystem-ManifestVersion: 1

Subsystem-SymbolicName: customTAISample-1.0;visibility:=public

Subsystem-Version: 1.0.0

Subsystem-Content: com.ibm.websphere.security; version="[1,1.0.100)",

com.ibm.ws.security.sample; version="[1,1.0.100)"

Subsystem-Type: com.ibm.websphere.feature

IBM-Feature-Version: 2

For more information, please see the Knowledge Center (formally Info Center)

24

25

2

5

Federated User Registry

Designed to federate multiple registries together. These registries are defined and combined under a single realm, providing a single view of a user registry and supporting the the logical joining of entries across multiple user repositories.

Liberty Profile 8.5.5.0 supports the federating of LDAP Repositories. – Only 1 or more LDAP configurations– Any other combinations of Basic Registry or Custom User Registry is

not supported.

How to use this feature?– Add the feature appSecurity-2.0 and ldapRegistry-3.0 to enable this

feature

– Specify more than one <ldapRegistry> tag to configure the LDAP

registry

– Specify the <federateRepository> tag to enable the federation of

multiple LDAP user registries in the server.xml

26

Example 1 LDAP Configuration

<server>

<featureManager>

<feature>appSecurity-2.0</feature>

<feature>ldapRegistry-3.0</feature>

</featureManager>

<ldapRegistry id="ldap" realm="SampleLdapADRealm"

host="smpc100.austin.ibm.com" port="636" ignoreCase="true"

baseDN="cn=users,dc=secfvt2,dc=austin,dc=ibm,dc=com"

bindDN="cn=testuser,cn=users,dc=secfvt2,dc=austin,dc=ibm,dc=com"

bindPassword="testuserpwd"

ldapType="Microsoft Active Directory"/>

</server>

27

Example Federating 2 LDAP server

<server>

<featureManager>

<feature>appSecurity-2.0</feature>

<feature>ldapRegistry-3.0</feature>

</featureManager>

<ldapRegistry id="TDS" realm="SampleLdapIDSRealm" host="ralwang.rtp.raleigh.ibm.com" port="389"

ignoreCase="true" baseDN="o=ibm,c=us" ldapType="IBM Tivoli Directory Server">

</ldapRegistry>

<ldapRegistry id="AD" realm="SampleLdapADRealm" host="smpc100.austin.ibm.com" port="389" ignoreCase="true"

baseDN="cn=users,dc=secfvt2,dc=austin,dc=ibm,dc=com"

bindDN="cn=testuser,cn=users,dc=secfvt2,dc=austin,dc=ibm,dc=com"

bindPassword="testuserpwd" ldapType="Microsoft Active Directory">

</ldapRegistry>

<federatedRepository>

<primaryRealm name="FederationRealm"> <== Virtual realm WAS Security sees

<participatingBaseEntry name="o=ibm,c=us"/> <== TDS Configuration

<participatingBaseEntry name="cn=users,dc=secfvt2,dc=austin,dc=ibm,dc=com"/> <== AD

Configuration

</primaryRealm>

</federatedRepository>

</server>

28

Protecting Liberty Passwords

Passwords can be stored in server.xml or passwords can be stored in a separate file using <include>

in server.xml to pull them into the liberty configuration <server>

<include location="${shared.config.dir}/myPasswordConfig.xml"/>

</server>

myPasswordConfig.xml should have a file permission set to only allowing appropriate access.

Passwords formats Clear Text

XOR – uses XOR encoding

AES – password are encrypted using AES 128

HASH – password are hashed with PBKDF2WithHmacSHA1

Note: Encrypting a password does not guarantee that the password is secure. File

permissions do...

SecurityUtility command A command line utility offering the ability to XOR, AES Encrypt, or Hash passwords

Password can then be cut and paste into server.xml

securityUtility -encoding=[xor|aes|hash]

Liberty offers a default key when using AES encryption. To over ride the key, you need to securityUtility -key=myStringKey

wlp.password.encryption.key=myStringKey must be specified in server.xml

Note: Recommend storing this property in a separate include protected file.

29

createSSLCertificate Command

Creates a default SSL certificate for use in server configuration. Generated keystore file key.js is

placed under /resources/security directory of the server specified in --server name. The key algorithm is

RSA and signature algorithm is SHA1 with RSA.

The arguments are:--server=name

Specifies the name of the Liberty profile server for keystore creation. Required.

--password=passwd

Specifies the password to be used in the keystore, which must be at least six characters in length. This option is

required.

--passwordEncoding=password_encoding_type

Specifies how to encode the keystore password. xor or aes. Default is xor.

--passwordkey=password_encryption_key

Specifies the key to be used when encoding the keystore password using AES encryption. This string is hashed to

produce an encryption key that is used to encrypt and decrypt the password. The key can be provided to the

server by defining the variable wlp.password.encryption.key whose value is the key. If this option is not provided,

a default key is used.

--validity=days

Specifies the number of days that the certificate is valid, which must be equal to or greater than 365. The default

value is 365. This option is optional.

--subject=DN

Specifies the Domain Name (DN) for the certificate subject and issuer. The default value is

CN=localhost,O=ibm,C=us. This option is optional.

30

3

0

Web Service Security

Web Services Security (WS-Security) is an OASIS standard that

describes how to secure Web services. WS-Security includes

XML signature, encryption, authentication, timestamp, etc..

- JAX-WS is supported; JAX-RPC is not

Used to provide Message level end-to-end security, which is

beyond and above traditional transport level security..

How to use this feature?

- Add Liberty feature of wsSecurity-1.1 and appSecurity-2.0...

31

Web Services Security Capabilities

Capability WAS full profile Liberty

SOAP Message Security 1.1 x x

Username Token Profile 1.1

PasswordText x x

PasswordDigest x

Key Derivation x

X.509 Token Profile 1.1

X509 V3 token x x

X509PKIPathv1 x

PKCS7 x

WS-SecurityPolicy 1.3 1.2 (Partial support ) x

Basic Security Profile 1.1 x

WS-Security Token as authentication and authorization token x x

SAML token profile 1.1 x

Kerberos Token Profile 1.1 x

WS-SecureConversation 1.3 x

WS-Trust 1.3 x

LTPA and LTPA2 token x

Generic and custom security token type (e.g. passticket) x

What new for WebSphere Application Server Security 8.5.5.3 and 8.5.5.4

33

IBM Confidential03/28/11

Open ID

• Enhance Authentication options

– SSO based on social platforms like Facebook

• Advanced/Easy Registration

– Reduce registration time

– Delivered in

– Liberty Profile 8.5.5.4 in the Liberty Repository

– Full Profile in 8.5.5.3.

What is OpenID Connect 1.0?

Open standard from non profit OpenIDFoundation.

It is a simple Identity protocol built on OAuth 2.0 and OpenID

• It allows client application to verify the identity of the End-User based on the authentication performed by an Authorization Server.

• It allows client to get user profile in an interoperable and REST-like manner.

• It supports web browsers and mobile devices .

It starts with OAuth2, adds provisions for:- Profile information/extended claims, Discovery, Dynamic registration, Session

Management, Revocation.

It can provide higher-assurance- Preregistration, strong binding- Certificate-level verification between server

Adoption so far – IBM, Google (deprecated OpenID/OAUTH), Sales Force, Paypal. Microsoft, Ping Identity, more…

34

Enhanced and simplified security for Web, Mobile,

Social and Cloud

OpenId Connect is a technology that provide a framework for identity interactions via REST like

APIs. It provides integration with external and internal Identity providers to support standard

and interoperable way for authenticating users and performing authorization.

OpenID Connect Essentials:

1. A simple identity layer on top of the OAuth 2.0 protocol. It

allows Clients to verify the identity of the End-User based

on the authentication performed by an Authorization Server,

as well as to obtain basic profile information about the End-

User in an interoperable and REST-like manner.

2. Combines the best features of OpenId and OAuth

integrated in a single identity protocol.

3. A Systems of Engagement friendly open standards

based interoperable and extensible identity protocol.

Customer benefits:

•Enables Liberty to participate in and integrate with other

OpenID Connect enabled sites.

•Use an account you already have to sign up, sign in, and

bring your profile, contacts, and data with you to any

compatible site.

•Allows clients of all types including browser-based, mobile,

and JavaScript clients, to request and receive information

about identities and currently authenticated services.

•Delegate user account creation and management, No

more password management

•Widely adopted by major Cloud Service Providers and

Social networking sites

OpenID Connect Provider

OP

Client Application

RPuser

1. Make request to client app

2. Redirect to OP for authorization code

3. User authenticates to OP

User authorizes client

4. Sends authorization code back to client via redirect

5. Exchange code with OP for access token, ID

token, and refresh token

6. Request user profile from OP using access token

Resource service 7. Request user resource from

resource server using access

token

Use

id token to

authorize

user

8. Response to user

35

36

Liberty

OpenID

Connect

Provider

Customer

User Registry

such as LDAP

WAS Full

Profile

VM

OpenID Connect

Built-in RP Support

cust 1

cust 2

Ruby or

Java Script or

whatever

Cloud App

Liberty Profile

VM

cust 3

OpenID Connect

Built-in RP Support

OpenID Connect Scenarios

36

OIDC Delivery

• WebSphere Application Server as a Relying Party

• The Security Container can be configured to use an external OpenID Connect Security

Provider instead of using its traditional User Registry Implementation.

• Supports an OpenID Connect Standardize Provider

• Delivered

– WebSphere Application Server Full profile 8.5.5.3

– WebSphere Application Server Liberty Profile 8.5.5.4 as part of the Liberty

Repository Delivery.

• WebSphere Application Server as a OpenID Connect Security Provider

• Liberty Only can be configured to act as a dedicated OpenID Connect Security Provider

that can be used by any OpenID Connect standard Relying Party solution.

• Delivered in Liberty Profile 8.5.5.4 as part of the Liberty Repository Delivery.

37

Tracking logged out LTPA Tokens • In a typical form log out or programmatic log out the LTPA token is removed from the cookie

and the Authentication cache. The user's session is also invalidated. The invalidated

session is typically what prevents user from login in again with that LTPA token back to that

same session. If the token was persisted or presented again, it is validated based the

token's expiration time and encryptions keys.

• When the trackLoggedOutSSOCookies is enabled the LTPA SSO token that are logged out

are tracked and if the token is presented again then it is not used and the user will need to

authenticate again. With trackLoggedOutSSOCookies is enabled when a user logs out we

keep track of the LTPA SSO token in a dynamic cache. So later if that token is presented

during a login there is a check to see if it's in the dynamic cache if it is the user will need to

authenticate.

• To enabled add the following to the server.xml file.

<webAppSecurity trackLoggedOutSSOCookies="true"/>

Note: This only works on the same server. Meaning the LTPA token can only be tracked on

the server where the user logged out. If that same LTPA SSO token is used on another

server it can be use for Single Sign On until it is logged out on the other server. If you require

multiple server support, TAM (ISAM) or equivalent product is recommended.

Delivered in Liberty in Dec 2014 8.5.5.4

38

WebSphere Application Server Security Statement of Direction

SPNEGO for Liberty Profile

• Available in Full Profile since WAS 6.1

• Liberty Profile Support

• Beta 12/2014

• Target GA 8.5.5.3 March 2015

• SPNEGO minimal configuration

<featureManager>

<feature>spnego-1.0</feature>

</featureManager>

40

41IBM Confidential

Setup / Configuration / Administration

krb5Config: The Kerberos configuration file name include path, contains

Kerberos configuration information. The default one will be used if you do not

specify it. See table 1. below for more detail.

krb5Keytab: The Kerberos keytab file name include path, contains one or more

Kerberos service principal names and keys. The Kerberos service principal

names format is HTTP/<fullyQualifyHostName>@KerberosRealm. The default

one will be used if you do not specify it. See table 1. below for more detail.

Note: krb5Config and krb5Keytab path support Liberty config variables

Table 1. Default location and file name for Kerberos config and keytab files

February 21, 2014

Operating System Default Kerberos configuration file name and location

Windows c:\winnt\krb5.ini or c:\windows\krb5.ini

Linux /etc/krb5.conf

other UNIX-based and z/OS /etc/krb5/krb5.conf

IBM i /QIBM/UserData/OS400/NetworkAuthentication/krb5.conf

41

42IBM Confidential

Setup / Configuration / Administration

skipForUnprotectedURI: do not use SPNEGO authentication for unprotetedURI. Default is true.

disableFailOverToAppAuthType: Disable fail over to application authentication type which

defined in the web.xml file such as FORM, BASIC. Default is true

trimKerberosRealNameFromPrincipal: Specifies whether SPNEGO removes the suffix of the

principal user name, starting from the @ that precedes the Kerberos realm name. Default is true.

addClientGSSCredentialToSubject: Specifies whether the client delegated GSSCredentials are

stored by SPNEGO web authentication. Default is true.

invokeAfterSSO: Specify whether SPNEGO will be invoked after SSO. Default is true

useCanonicalHostName: Specifies whether to use the canonical form of the URL/HTTP host name

in authenticating a client. Default is true.

servicePrincipalNames: Specifies a list of Kerberos service principal that will be used to validate the

SPNEGO token.

spnegoNotSupportedErrorPageURL: Specifies the SPNEGO not supported error page URL. If

it's not specified, will use the default one.

ntlmTokenReceivedErrorPageURL: Specifies the NTLM token received error page URL. If it's not

specified, we will use the default one.

February 21, 2014

42

43IBM Confidential

Setup / Configuration / Administration

Example of a Liberty server.xml

SPNEGO with Kerberos configuration and keytab file at resources

security directory

<featureManager><feature>spnego-1.0</feature> />

<spnego

krb5Config=“${server.config.dir}/resources/security/myKrb5.conf”

krb5Keytab=“${server.config.dir}/resources/security/myKrb5.keytab”>

</spnego>

February 21, 2014

43

44IBM Confidential

Liberty Authentication Filter

Based on a URL pattern, filter can be used to identify

the Authentication implementation to be used.

A way for some Web Application to use SPNEGO as an

example.

Specifies a set of condition which are met or not met. These

conditions are logical AND together so if one condition

fails, the entire filter fails.

If there is no filter configuration, all protected requests will

use the authentication feature configured.

Delivered in Liberty Dec, 2014 Beta. Target GA 8.5.5.5 March

2015.

Initially available for SPNEGO beta and in the beta to

support openID and OpenID Connect Relying Party.

February 21, 2014

44

45IBM Confidential

Authentication Filter Example

Configure authFilter for HTTP header requests that have URL patterns of

/snoop.

<authFilter id=”myAuthFilter”>

<requestUrl urlPattern="/snoop" matchType="contains” />

</authFilter>

Configure authFilter for HTTP header requests that have host name

host1.austin.ibm.com.

<authFilter id=”myAuthFilter”>

<host name=”host1.austin.ibm.com” matchType=”equals” />

</authFilter>

February 21, 2014

45

46IBM Confidential

Authentication Filter Example

Configure authFilter for HTTP header requests that have URL patterns of

/snoop for SPNEGO Implementation.

<spnego disableFailOverToAppAuthType="true"

krb5Config=“${server.config.dir}/resources/security/myKrb5.conf”

krb5Keytab=“${server.config.dir}/resources/security/myKrb5.keytab”>

<authFilter >

<requestUrl urlPattern="/snoop" matchType=“contain” />

</authFilter >

</spnego>

February 21, 2014

46

47IBM Confidential

Authentication Filter Config Element and Attributes

remoteAddress: The remote address element

ip: Specifies the server remote IP address.

host: The host element

name: Specifies the remote host name.

requestUrl: The request URL element

urlPattern: Specifies the URL pattern.

userAgent: The user agent element

agent: Specifies the agent name such as Firefox, IE, etc.

matchType: The default value is contains.

equals , contains, notContain, greaterThan, lessThan

February 21, 2014

47

WebSphere Application Server Java EE 7 Security

• Liberty Profile

• Full Profile • Already Java EE6 compliant

• Our statement of direction will be to add Java EE7 and Security related updates.

<#>

Feature Target Dates

Servlet 3.1 Delivered in 8.5.5.4

JACC Feb, 2015 Beta

JASPI Feb, 2015 Beta

CSIV2 March, 2015 Beta

Java 2 Security March, 2015 Beta

Liberty Considerations, Like your input….

JAAS as a Feature

Complete User Registry Federation

Member Management API

SAML

Security Audit

Multiple Security Domain

Multi tenant

Enhanced cert/key management

LocalOS Registry support (except z/OS)

49

Future Consideration

Questions?

50

Notices and DisclaimersCopyright © 2015 by International Business Machines Corporation (IBM). No part of this document may be reproduced or transmitted in any form without written permission from IBM.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM.

Information in these presentations (including information relating to products that have not yet been announced by IBM) has been reviewed for accuracy as of the date of initial publication and could include unintentional technical or typographical errors. IBM shall have no responsibility to update this information. THIS DOCUMENT IS DISTRIBUTED "AS IS" WITHOUT ANY WARRANTY, EITHER EXPRESS OR IMPLIED. IN NO EVENT SHALL IBM BE LIABLE FOR ANY DAMAGE ARISING FROM THE USE OF THIS INFORMATION, INCLUDING BUT NOT LIMITED TO, LOSS OF DATA, BUSINESS INTERRUPTION, LOSS OF PROFIT OR LOSS OF OPPORTUNITY. IBM products and services are warranted according to the terms and conditions of the agreements under which they are provided.

Any statements regarding IBM's future direction, intent or product plans are subject to change or withdrawal without notice.

Performance data contained herein was generally obtained in a controlled, isolated environments. Customer examples are presented as illustrations of how those customers have used IBM products and the results they may have achieved. Actual performance, cost, savings or other results in other operating environments may vary.

References in this document to IBM products, programs, or services does not imply that IBM intends to make such products, programs or services available in all countries in which IBM operates or does business.

Workshops, sessions and associated materials may have been prepared by independent session speakers, and do not necessarily reflect the views of IBM. All materials and discussions are provided for informational purposes only, and are neither intended to, nor shall constitute legal or other guidance or advice to any individual participant or their specific situation.

It is the customer’s responsibility to insure its own compliance with legal requirements and to obtain advice of competent legal counsel as to the identification and interpretation of any relevant laws and regulatory requirements that may affect the customer’s business and any actions the customer may need to take to comply with such laws. IBM does not provide legal advice or represent or warrant that its services or products will ensure that the customer is in compliance with any law.

51

Notices and Disclaimers (con’t)

Information concerning non-IBM products was obtained from the suppliers of those products, their published announcements or other publicly available sources. IBM has not tested those products in connection with this publication and cannot confirm the accuracy of performance, compatibility or any other claims related to non-IBM products. Questions on the capabilities of non-IBM products should be addressed to the suppliers of those products. IBM does not warrant the quality of any third-party products, or the ability of any such third-party products to interoperate with IBM’s products. IBM EXPRESSLY DISCLAIMS ALL WARRANTIES, EXPRESSED OR IMPLIED, INCLUDING BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE.

The provision of the information contained herein is not intended to, and does not, grant any right or license under any IBM patents, copyrights, trademarks or other intellectual property right.

• IBM, the IBM logo, ibm.com, Bluemix, Blueworks Live, CICS, Clearcase, DOORS®, Enterprise Document Management System™, Global Business Services ®, Global Technology Services ®, Information on Demand, ILOG, Maximo®, MQIntegrator®, MQSeries®, Netcool®, OMEGAMON, OpenPower, PureAnalytics™, PureApplication®, pureCluster™, PureCoverage®, PureData®, PureExperience®, PureFlex®, pureQuery®, pureScale®, PureSystems®, QRadar®, Rational®, Rhapsody®, SoDA, SPSS, StoredIQ, Tivoli®, Trusteer®, urban{code}®, Watson, WebSphere®, Worklight®, X-Force® and System z® Z/OS, are trademarks of International Business Machines Corporation, registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at "Copyright and trademark information" at: www.ibm.com/legal/copytrade.shtml.

52

Thank YouYour Feedback is

Important!

Access the InterConnect 2015 Conference CONNECT Attendee Portal to complete

your session surveys from your smartphone,

laptop or conference kiosk.