Web Sphere Portal Security

IBM WebSphere Portal Security Concepts

Omaha WebSphere Users GroupDon Jones

Agenda

§ Portal Security Overview and Basics

§ Authorization (Access Control)§ Portal’s Role-based Security model – Role Templates, Roles, Inheritance

§ Integration with external security products

§ Authentication§ Includes WMM setup options and WAS Authentication relationship

§ Outbound SSO from Portal§ Including WSRP

§ Not discussed here: Auditing, Java 2 Security support

Portal Security Overview and Basics

§ Portal is a WAS Form-based Login application§ Requires WAS Global Security to be active (in production)

§ Portal authentication really is WAS Authentication§ So Trust Association Interceptor (TAI) works

§ Inbound (to Portal) SSO is really a question of inbound SSO to WAS

§ Unlike Auth’n, Portal Access Control is not integrated with WAS§ (Most) Portal resources are not URL-visible

§ Role-based, but with Portal-unique way of defining Roles

§ Portal outbound SSO (from Portlets to other apps) involves the Credential Vault framework§ Key word is “framework” – with some out-of-the-box implementations

Portal Access Control

Role, role, role your boat….


§ Role-based Access Control with specific way of defining Roles

§ For definition purposes: A Role is a named set (or group) of Permissions§ A Permission is an {action, portalResource} tuple – for example:

§ {view, WelcomePage}§ {edit, StockWatchPortlet}

§ This is consistent with J2EE definition

§ Usually you don’t have to worry about what specific permissions make up a Portal Role§ Internal detail: Portal at the lowest level is looking for whether you have a

specific permission set which grants you rights to do what you’re trying to do – not just making “isUserInRole()” calls….

§ You’d need to be in at least one Role or set of Roles that would contain the necessary Permission(s)

Role Concept – Three sets of mappings/relationships

RolePermission = (action, resource)

User Subsystem

User Group (groups may be nested)

User

Editor@Weather_Portlet

Manager@Welcome_Page

Role AssignmentPermission-to-Role mapping Role-to-Principal

mappingInheritance by Group membership


§ Portal builds the Permission tuples for Portal Roles by combining (cross product) the actions in a Role Template with a subtree of Portal resources (examples and pictures follow)

§ A Role Template is not a Role, until it is applied to a Portal resource subtree§ “Administrator” is not a Portal Role.

§ “Administrator@WelcomePage” is a Portal Role

§ Portal Roles created by applying Role Templates to the root of aPortal resource subtree§ Portal Inheritance Blocks exempt resources (resource sub-subtrees) from

being part of the Role

§ Propogation blocks for all child nodes, Inheritance blocks for one specificchild node

§ Role name is <template-name>@<resource-subtree-root>

Portal DB

Access Control picture

Portlet

Page1 Page2

resources

Administrator@Portal

User@Page1

Administrator@Page1

User@Page2

Administrator@Page2

User@Portlet1

…

(Appl Roles not shown)

Portal Roles

User1

Group1

User2

Group2

User/Group registry

WMM MR, or user registry provisioning, can affect what groups a user is in

Permission-to-Role mappings (sets of privileges on resources)

Principal-to-Role mappings

*Can be directly controlled by external service, independent of WMM groups*

Portal Role Types

§ Imply/provide the “actions” of the (action, resource) tuples in a Role

§ Users are allowed to view portal resources§ Privileged Users are allowed to create and personalize private resources

§ Editors are allowed to create and edit shared resources

§ Managers are allowed to create, edit, and delete shared resources

§ Delegators are allowed to grant access to other principals

§ Security Administrators are allowed to grant access on (or for) a resource§ Administrators are allowed to do everything

§ These are NOT Roles – these are Role Types (or Templates) – they are used to build Portal Roles (aka Role Instances) by applying the Types to the Portal resource tree.

Administrator

User

Editor PrivilegedUserDelegator

ManagerSecurityAdministrator

Protected Resource Hierarchy (simplified)

Teller page

page 4 page 5

page 6

page 3

page root External AZN

page 1 app 2Teller app

app root

portlet 1 portlet 2

root

Protected Resource Hierarchy

Virtual ResourceVirtual Resource

Virtual root resource of the protected resource hierarchyVirtual root resource of the

protected resource hierarchy

Protected ResourceProtected Resource

Role Instances

Teller page

page 4 page 5

page 6

Editor

page 3Editor

page root External AZN

page 1Manager app 2Teller app

app root

portlet 1 portlet 2Editor

User

root Administrator

Editor

Administrator

Protected Resource Hierarchy

IRBAC role instance:Manager@page1

IRBAC role instance:Manager@page1

Virtual ResourceVirtual Resource

Domain Root Resourcefor Editor@Teller page

Domain Root Resourcefor Editor@Teller page

Inheritance Block forroles of type Editor

Inheritance Block forroles of type Editor

Virtual root resource of the protected resource hierarchyVirtual root resource of the

protected resource hierarchy

Protected ResourceProtected Resource

Portal role-based access control

§ Based on identity (from WAS) and group memberships (from WMM)§ Nothing else (at the pure Access Control level)

§ WP6 Personalization-based extensions on Portal rendering (“Attribute-based Admin”) are not truly “security” – they further filter what is chosen for rendering but don’t limit what is accessible

§ Simple additive semantics – no “except” or “but not” or “IFF A and B”

§ No multi-level step-up (yet): either authenticated or not, either allowed or not

§ Later (Authentication) discussion about how WAS gets your identity, and how WMM gets your group memberships – lots of flexibility, sometimes allowing/requiring custom code§ Portal needs lists of groups for administration (granting roles to groups) and lists of groups of

which a user is a member at runtime for decisions.

§ Very occasionally, Portal needs to enumerate the members of a group

Portal “required roles” for activities

§Many activities in Portal require multiple Portal roles§ See a portlet on a page -> at minimum, User@Page + User@Portlet

§ Pages and Portlets are different Portal resource subtrees – no inheritance§ Application Roles in V6 will begin to address this

§ InfoCenter has a table with required roles for Portal activities (hopefully all)§ http://publib.boulder.ibm.com/infocenter/wpdoc/v510/index.jsp?topic=/com.i

bm.wp.ent.doc/wpf/sec_acc_rights.html

“Business Roles”

§ Arbitrarily-named roles that make sense in the customer’s environment§ “Teller”

§ “Assistant Undersecretary Minister of Silly Walks”

§ These are Portal V6+ “Application Roles”

§ Often, modeling business roles as registry groups works§ Tie all access control, for various applications/portlets/pages/etc, to groups in a

common registry (assumes there is a common registry) – a group named “Teller”, for example

§ Actively manage membership in these groups as a way to manage access

§ Provisioning process (Tivoli Identity Mgr) can have sophisticated logic for putting users into groups – model Business Roles in this logic§ Set up Portal access control roles for these groups ahead of time

Delegated Administration

§ Wpsadmin doesn‘t have to do it all§ Can set up smaller Role sets to define sub-administrators

§ Can optionally virtually subdivide user population through group-membership-based access control § (be careful, can be costly in admin performance)

§ Does require non-trivial role setup activity – trade granularity for simplicity (triviality?) of setup

§ Fine grained access control delegation model:§ A user can grant only those roles to other users that the user possesses

him/herself

§ An Administrator can only delegate the authority to grant those roles, that he/she possesses

Access Control Administration via Portlets

Access Control Administration via XmlAccess

<content-node action="update" uniquename="wps.My Portal">

<access-control>

<role-block type="propagation" actionset="User"/>

<role actionset="Administrator" update="set"><mapping subjectid="uid=hsimpson,o=default“ subjecttype="USER"

update="set"/>

</role>

<role actionset="User" update="set">

<mapping subjectid="anonymous portal user" subjecttype="USER" update="set"/>

</role>

</access-control>

</content-node>

Access Control Administration via Scripting

§ Allows display, modification of Role Mappings and Role Blocks for:§ Content_Nodes (Pages, Labels, URLs)§ Portlet_Definitions§ Portlet_Applications§ Web_Modules

§ Sample:wsadmin>$Portlet search application namehas "News"_2_0830M4HTFF0GHQ05_43wsadmin>$PacList view [$Access getacl application _2_0830M4HTFF0GHQ05_43]PacList[_2_0830M4HTFF0GHQ05_43]wsadmin>$PacList list User all<< Anonymous User >>

Externalization Approach

User Registry

Tivoli Access ManagerPortal

o4 o5

o3o2

o6

o1

Editor@o1

{(view,o1),...(view,o6),(edit,01),...(edit,06)}

Tivoli Access Manager

Editor@o1

Portal Resource Topology

Portal DB

Portal Admin TAM Admin

Editor

Integration of External Access Control Providers

§ Same model since 5.0: Role-to-Principal mapping is externalized, NOT Permission-to-Role mapping§ Membership in role is externalized; Definition of role is not

§ EX: TAM ACLs with arbitrary permissions can’t define Portal roles; the only TAM ACL permission Portal understands is “[wps]m” for membership in Role

§ For each resource within the portal, role membership is either determined by WP access control or by an external authorization provider (never mixed)

§ Role inheritance does NOT inherit between internally and externally protected resources (in either direction)

§ Roles and role blocks are always created within the portal by anadministrator using dedicated portal UIs or XMLAccess§ Role blocks are part of role definition, therefore controlled internally

TAM versus SiteMinder

§ TAM gives Portal a “getEntitlements()” API that makes “bulk”role membership information available with a single call

§ For SiteMinder, Portal is required to make individual calls for each externalized role

§ For this reason, TAM + Portal scales better for external authorization

§ For SiteMinder, try to minimize the number of roles placed under external membership control

§ Some Workplace apps have issues with proxies (like WebSEAL) or HTTP-plugin-based security functions (like SiteMinder)§ Most recent releases seem to have worked these out - Check w/

Workplace security specialists

Extending External Authorization

§ The TAM and SiteMinder integration code is plugged into a non-public Portal SPI called “ExternalAccessControl”§ While not public, this SPI is “disclosable” just like the

MemberRepository SPI under WMM§ Requires an AECI but once that’s in place the use of this SPI would be supported § Reason it’s not public: not JSR115 compliant in its current form

§ This interface can be used to hook Portal role membership decisions directly to “your” access control decision infrastructure§ Via “aliases” set on Portal roles – name strings that are meaningful to “your” access

control system – *or* by externalizing the Portal role name§ Portal calls out to ESM implementation for a list of roles and/or aliases of which a user

is a member

§ Remember, this is only externalizing Portal role membership control, NOT Portal role definition control§ This has existed for some time but is not widely advertised

§ More customers use MR than ESM

Portal DB

Access Control picture

Portlet

Page1 Page2

resources

Administrator@Portal

User@Page1

Administrator@Page1

User@Page2

Administrator@Page2

User@Portlet1

…

Portal Roles

User1

Group1

User2

Group2

User/Group registry

WMM MR, or user registry provisioning, can affect what groups a user is in

Permission-to-Role mappings

Principal-to-Role mappings

*Can be directly controlled by external service, independent of WMM groups*

Externalization Approach (via alias)

User Registry

Portal

o4 o5

o3o2

o6

o1

Editor@o1

Alias=xyz

{(view,o1),...(view,o6),(edit,01),...(edit,06)}

Your Cool Access Control

xyz

Portal Resource Topology

Portal DB

Portal Admin YCAC Admin

Editor

Portal Access Control Feature List

§ Role-based instance-level access control

§ Propagation + Inheritance Blocks

§ Ownership & private resources

§ Fine-grained delegated administration

§ Support for nested user groups

§ Integration of external authorization providers (TAM + SiteMinder)

§ Administration Portlets + scripting support

WAS Access Control and Portal

§ In WAS, “/myportal/*” is set up with a required WAS/J2EE role of “Everyone” to access it

§ By default, “All Authenticated Users” is assigned to this role

§ This can be changed – only allow certain users/groups to get to /myportal

§ /portal is unprotected in WAS – no security context set up –publicly available

§ Virtual Portals now have dependable URLs§ /myportal/virtualPortalName

§ Can use this for WAS security as well as proxies

§ Requires changing Portal’s web.xml and other WAS security-related files (ibm-application-bnd.xmi)

Portal Authentication

And SSO and WMM and …

WP Authentication

§WP depends on WAS Security to set user identity for a request

§ This requires WAS Global Security to be active (in production) even if behind a security proxy

§ Login to Portal is really login to WAS§ If you’ve logged in to WAS, you’re logged in to Portal

§ If you log in to Portal, you’re really logging in to WAS

WAS: LTPA versus JSESSIONID

§ Two different things – two (semi-)independent cookies§ LTPA is login/authentication state§ JSESSIONID is session state

§ LTPA has a fixed lifetime, regardless of activity§ Set in WAS Security/SSO config

§ JSESSIONID is kept alive by activity, has an inactivity timeout§ Set in WAS Session Manager, cell/server/application levels

§ Portal does NOT currently support URL rewriting to replace JSESSIONID cookie L§ Portal does NOT currently support renaming JSESSIONID

cookie L (this may have been fixed in WP6?)

WP Authentication

§ Portal is a WAS “Form-based login” App§ Portal supplies a form (\portal public page with login portlet, or the old login

form)

§ Portal configures WAS Security to redirect to this form if a request to \myportal with no authentication credentials is received§ This redirection is done before Portal ever gets control

§ Portal code handles the login form submission (it does not go toj_security_check)§ “Handle” means Portal calls WAS JAAS Login APIs to authenticate the user –

uses the “PORTAL_LTPA” LoginContext§ WAS makes calls down through its own UserRegistry interface to search for a

DN for the login shortname, and authenticate the password§ For the LDAPUserRegistryImpl, this authentication would typically be an LDAP

“bind”

Portal and WAS Authentication “flow”

WAS SecurityWAS

Security

WAS LDAP User Registry configuration

(e.g. via admin console)

WAS LDAP User Registry configuration


LDAPLDAP

Login via UI,XMLAccess,

Scripting submitted


Scripting submitted

WAS Security API (JAAS)

Portal login handler


Search, “bind”(validate id/pw), fetch DN, fetch group memberships

Retrieve UserRetrieve User WMM (portal component)

WMM (portal component)

Fetch attributes by DN (user profile)

Fetch nested group memberships

Independent of WAS lookup but based on DN from WAS

Portal/WMM LDAP config (wmm.xml)


ID/P

W

okay?ID

/PW

okay?

Variation: Use WMM for WAS registry access

§ Portal provides a UserRegistry implementation that can be installed in WAS to use WMM as the user registry for WAS

§ This is the “WMMUR” that is used for virtual portal realm support

Portal and WAS Authentication “flow”

WAS SecurityWAS

Security

WAS “Custom User Registry” configuration (e.g. via admin console)

WAS “Custom User Registry” configuration (e.g. via admin console)

LDAPLDAP


Scripting submitted


Scripting submitted

WAS Security API (JAAS)


Portal login handler Retrieve UserRetrieve User WMM

(portal component)

WMM (portal component)



Independent of WAS lookup but based on DN from WAS



ID/P

W

okay?ID

/PW

okay?

(WMMUR)

Search, “bind”(validate id/pw), fetch DN, fetch group memberships

Portal and LDAP

§ No “required schema” in LDAP for Portal

§ WAS and WMM are very (or at least somewhat) flexible in configurability for various LDAP setups§ DIT layouts

§ Objectclasses and objectclass combinations

§ Some complex configurations may require hand setup because the configtasks can’t handle everything that WMM can handle, for example

Virtual Portal “Realms” in WMM

§ New in 5.1 and later§ Subset of the WMM namespace

§ Subsets of the WMM namespace, which can be built from Multiple LDAPs

§ Scope a virtual portal to an LDAP subset & vice versa§ Only users from that realm can log on to a Virtual Portal§ Only users from that realm can be “seen” from that Virtual Portal

§ Requires WMM User Registry (WMMUR)§ These realms are actually WMMUR constructs, using WMM “node”

concept§ enable-security-wmmur-ldap or enable-security-wmmur-db config tasks§ Virtual Portals do NOT require vp realms – if all users can access all VPs

§ NOT the same as WAS UR “realm”§ WAS realm is usually the LDAP server hostname

Portal and external security (authentication)

§ Anything “in front of” WAS that does the authentication

§ Login dialog conducted by front end security§ May use Portal to serve up the login page, but Portal no longer handles the

login form submission

§ Front end asserts already-authenticated end user identity to WAS§ Trust Association Interceptor (TAI) architecture

§ TAM has other options (LTPA junctions)

§§ TAI is a WAS feature, not a Portal featureTAI is a WAS feature, not a Portal feature§ Documented in the WAS InfoCenter

§ Portal has no idea about presence or absence of TAI, or how WAS gets the user identity

§ IBM only provides one (1) TAI – that for TAM/WebSEAL. *ALL OTHER SECURITY VENDORS MUST PROVIDE THEIR OWN TAI!!!!*

Portal and WAS and TAI Authentication “flow”

WAS SecurityWAS

Security

WAS User Registry configuration


WAS User Registry configuration


LDAPLDAP

Login dialogLogin dialog

Search, fetch DN, fetch group memberships

Portal and WMM

(portal component)

Portal and WMM

(portal component)



Independent of WAS lookup but based on DN from WAS (from TAI)



TAITAI

Security Front-endSecurity

Front-end

Asserts

IdentityA

ssertsIdentity WAS lookup okay

WAS lookup okay

(WMMUR)

All id/pw validation done by front end

End user identity flow from TAI to WAS to WP

§ Generally, the user identity must be “the same DN” between front end security through TAI (if present) to WAS and WP

§ Ideal: Front end/TAI, WAS, and WP should all use the same user registry

§ Possible to map between different registries for front end .vs. WAS/WP§ This is complex, leads to hard-to-debug problems

§ TAI can assert a security shortname that WAS will “look up” using search

§ TAI++ can set end user identity, bypassing lookup§ Portal still needs to be able to look up profile info for that user’s DN

§ Except in VERY rare circumstances, WAS and WP should always use the same user registry§ Portal lookup based on “DN” from WAS

WMM Configurations in Portal

WMM proprietary database (*not* your own database) for users and groups

(No customer does this in production that I know of)

Portal-supplied “WMM DB CUR”UserRegistry impl

(not WMMUR)

WMM DB only

Custom MemberRepository implementation under WMM – either complete or “Decorator”around LDAP.

Supported but not public – requires AECI.

Custom UserRegistry or WMMUR

Custom

Portal-supplied LDAP MR plus optional WMM profile extension lookaside db (“extended attributes”) plus additional WMM db holding groups (users from LDAP)

LDAPRegistryImplor WMMUR

Application groups

Portal-supplied LDAP MR plus optional WMM profile extension lookaside db (“extended attributes”)

LDAPRegistryImplor WMMUR

LDAP+Lookaside

Portal/WMM setupWAS setupConfig “name”

WMM configurations in support of Portal Access Control

§ Remember we said Portal Access Control is based on identity (from WAS) and group memberships (from WMM)

§ There are lots of clever ways to tell WMM about groups§ Every time every user logs in, Portal asks “What groups does this user belong to?” – that

answer MUST be efficient to obtain

§ “memberOf” support is best (fastest)§ *configurable* attribute on user profile that WMM interprets as a list of group DNs§ Values here should line up with list of groups returned to a search request for security Administration

§ Static groups (explicit membership lists) is next best

§ Dynamic groups from LDAP are supported§ Caution: expensive to answer “What groups does user belong to” with (lots of) dynamic groups

Probably CPU intensive for either the Portal or the LDAP server

§ Plug code under MemberRepository interface of Portal/WMM to provide or filter group (and user) info§ Supported but not fully public – requires AECI

Single Sign-On

Portal Single Sign-On Realms

AuthenticationProxy

Client

Client-Web App SSO

Client

ClientPortalServer

Back EndApplication

Back EndApplication

Back EndApplication

Client

Portlet

Portlet

Portlet

WebApplication

OtherApplication

Portal-Back End SSO

Overview: Portal Single Sign-On

§ Client-to-Web Application SSO § Application server built-in SSO support (LTPA)

§ Authentication proxy SSO support (WAS Trust Association Interceptors)

§ WAS (therefore Portal) support for Federated Identity (Liberty/SAML) via WebSEAL or other front-end security service, brought in to WAS via TAI or other mechanism

§ Portal-to-Back End SSO§ Portal Credential Vault

§ Credential Vault Portlet Service and Active and Passive Credential Objects§ Credential Vault Adapter SPI§ Default simple DB storage vault implementation

§ ConnectionFactories provided via JCA / WAS

Windows Desktop to Portal Front-End SSO

§ Supported out-of-the-box today by Tivoli Access Manager § WebSEAL supports SPNEGO, id passed to WAS via standard TAI

§ SiteMinder can do this too

§ Not supported out-of-the-box by WAS standalone yet§ Coming soon

§ But well known how to do this via ISSW services

§ SPNEGO TAI++ implementation already built by ISSW

§ Kerberos Authentication Technology Preview in WAS 6§ May be used with Portal 5.1.0.x for Windows SSO -> not tested so far§ http://www-106.ibm.com/developerworks/websphere/downloads/kerberos.html

Single Sign-On Models

§ Use of delegatable tokens§ If a trustable token can be re-used to indicate user identity downstream, take

advantage of that

§ Examples: LTPA for IBM servers within a common security domain; Kerberos tickets (at least in theory)

§ Establish trust and assert end user identity§ WAS’s TAI model is an example

§ Only 1 “secret” to manage per endpoint pair – to establish the trust – rather than per-user secrets

§ May still require an identity mapping – but no per-user password mapping

§ à only works when Back end apps are able to accept this model; not all can

§ ID/PW passed to back end and re-authenticated§ Requires vault store creation/maintenance

§ Worst choice other than “no SSO”, but sometimes (often?) there’s no other choice

§ “Veneer” front-end security – back end unsecure or accessed with admin id – not really SSO

Portal to Backend SSO: WP Credential Vault

§ Portal’s *FRAMEWORK* for back-end SSO

§Much more than just a store for mapped IDs/PWs§ That’s just the bottom layer – the default storage vault implementation

Vault Adapter Interface

Portlet Portlet Portlet

Defa

ult

Adap

ter

DefaultVault Impl.

TAM GSOLockbox

TAM

Adap

ter

Cust

omAd

apte

r

Custom Vault

Credential Portlet Service

A Portlet Service for storing and retrieving SSO Credentials including the user‘s JAAS Subject that was built during login.

+

A vault adapter interface to integrate vault implementations like the Tivoli Access Manager Global Sign-On Lockbox

+

A basic vault implementation (the default credential store)

+

An Encryption Exit for the basic vault implementation (default impl is Base64)

Portal to Backend SSO: WP Credential Vault

EncryptionExit

Not just an id/password store – that’s just the bottom layer

WP Credential Vault Structure

§ Vault Segments contain Vault Slots

§ Vault Slots represent the credentials for one or more users

§ Segments (and Slots in them) either user managed or administrator managed

§ Slot types:§ System Credential Slot (administrator

managed): System wide Credentials

§ Shared Credential Slot (user managed): User specific, accessible by all Portlets

§ Portlet Private Slot (user managed): User and Portlet specific

VaultImplementations

Internal External

Vault Segment A1

Slot c

Vault Segment U

Slot a Slot b

Vault Segment A2

Slot x Slot y

VaultAdapter

VaultAdapter

VaultAdapter

WP Credential Vault Objects

§ Passive Credential Objects:§ Container for credential secret§ Portlet must be coded to use the secret to do authentication with backend§ SimplePassive§ UserPasswordPassive§ JaasSubjectPassive

§ Active Credential Objects:§ Automatically authenticate and create a backend connection

(encapsulated/abstracted from Portlet code)§ HttpBasicAuth§ HttpFormBasedAuth§ JavaMail§ LtpaToken§ SiteMinderToken§ WebSEALToken§ ...

§ Additional custom Credential Objects can be coded, registered and used (although this has not been common)

Active Credentials

3. Get Connection

1. R

etrie

veC

rede

ntia

l

2. Retrieve Secret

Vault Store

Backend SystemBackend SystemPortal EnginePortal Engine

Credential VaultPortlet Service

Credential VaultPortlet Service

Por

tlet A

PI PortletPortlet

ActiveCredential

ActiveCredential

5. Send Business Request

4. Authenticate

WP Credential Vault - Public API/SPI

§ Legacy PortletService: com.ibm.wps.portletservice.credentialvault. CredentialVaultService

§ JSR PortletService (since 5.1.0.1): com.ibm.portal.portlet.service.credentialvault. CredentialVaultService

§ EncryptionExit (since 5.1.0.1): com.ibm.portal.portlet.service.credentialvault.spi.EncryptionExit

Portlets must be coded to use Credential Vault

§ Portlets must be explicitly coded to use Credential Vault objects§ True for either Active or Passive Credential Objects

§ Object instances encapsulate/abstract details of back-end authentication

§ Same portlet in different deployments might use different Credential Vault object instances (if portlet so coded)

§ All objects extend same base classes, so portlet coding for multiple types should be minimal effort

Credential Vault is not “magic”

§ Management of identity mappings must still be done§ Including mapped passwords, if necessary

§ Portlet responsible, sample code available§ Handle “no mapping found” or back-end authentication failure cases

Including “expired, must change” – hard to detect§ Prompt for (new) password§ Store new password via Cred Vault object APIs, retry back-end access

§ Recognized as a shortcoming, work being done to address this§ Make it a Portal or system service, requiring at least “much less” code

from the portlet programmer

WSRP – A “Special” SSO case

Overview WSRP

§ Web Services for Remote Portlets (WSRP)§ Industry standard for

presentation oriented Web Services

§ Spec Lead: IBM

§ Included since WPS 5.0.2

§ Producer Side: Portlets can be provided as WSRP Services

§ Consumer Side: § Setup Producer entity§ Integrate WSRP Services in form of

Portlets from a Producer

Internet/ Intranet

Internet/ Intranet

Portal

Port

let A

PI

WSR

P

GenericPortletProxy

LocalPortlets

WSRPServices

Publish/Find Web Services (SOAP)

UDDI Registry

WSR

P

LocalPortlets

LocalPortlets(JSR 168WPS 4.x)

WSRPServices

WSRPServices

Application and Content Providers

Websphere Portal

3rd Party Content/ Application Provider

WSRP Overview

§ Authentication:§ Submit of user profile

§ Support of WS-Security

§ SSL client authentication

§ Authorization:§ Usage of Portal Access Control

WSRP Authentication - Submit of user profile

§ Basic attributes submitted in Soap message

§ Used for generating personalized content

§ User Profile info does NOT result in a true Security Context established on Producer side§ WAS and the Web Services stack, by default, do not recognize this

application-level flow

§ Not intended for access control decisions§ No mechanisms in place to make this a secure equivalent of LTPA, for

example

WS-Security Standard

§ Describes SOAP header enhancements to provide message integrity and confidentiality§ By leveraging XML Signature and XML Encryption

§ Provides general purpose mechanism to attach security tokens to messages§ No specific type of security token mandated§ Support for multiple security token formats§ Provides token profiles for

§ Plain text tokens (Username, Username/Password) (standardized)§ Binary tokens

X.509 certificates (standardized)Kerberos tickets (working draft)

§ XML tokensSAML assertions (working draft)XrML

§ V1.0 OASIS Standard, 6th April 2004

WS-Security

§ WP WSRP implementation is JSR109 complient§ Can utilize whole spectrum of WAS WS-Security support

§ WAS WS-Security support§ WAS 5.x based on a pre-1.0 draft (dated from November 2003)§ Full support for WS-Security 1.0 planned for next WAS releases

§ WP WSRP WS-Security usage§ User identity propagation (provided with WP 5.1)

§ Using WAS LTPA token support to enable SSO in LTPA security domains§ Users authenticated to the WSRP Consumer are also seamlessly authenticated

to remote WSRP Producers enabling SSO experience for remote Portlets used§ Requirements: shared User Registry, common LTPA keys§ Can be used for Authorization decisions on Producer side

§ Potentially can be configured to support message level integrity and confidentiality if needed§ Currently SSL can be used for these purposes on the transport level

WS-Security

Consumer Producer

SOAP HEADER SOAP BODY

BinaryToken containing LTPA token

SOAP HEADER SOAP BODY

Request Data

Response Data

Common LDAPUser registry

/LTPA domain

BrowserLTPA token

Outlook WS-Security

SOAP Foundation

WS-Security

WS-SecureConversation

WS-Trust WS-Privacy

WS-Policy

WS-PolicyFramework

WS-PolicyAttachments WS-PolicyAssertions

WS-AuthorizationWS-Federation

Pol

icy

Laye

rFe

dera

tion

Laye

r

Today

Tim

e

WSRP Authentication - SSL client authentication

§ Certificate based client authentication

§ User ID in certificate

§ One identity per Consumer possible (that of the Consumer cert)

§ UI authentication still form based through separate WSRP WAR

§ Can be used for Authorization decisions on Producer side§ Remember Security Context is from the Consumer cert

§ Combination with WS-Security: § LTPA token identity has precedence

§ Combination with Submit of User Profile:§ Identity from SSL setup (Consumer cert) used for authorization

§ Submitted User Profile used for personalized content§ Portlet or back-end must be coded to do so

WSRP Authorization

§ Producer Side:§ Providing / Withdrawing of Portlet definitions protected via Portal Access

Control

§ Configuration option to enable Portal Access Control Checks:§ When viewing / editing Portlet definitions§ Can only be used with SSL client certificate / WS-Security

§ Consumer Side:§ Producer management protected via Portal Access Control

§ Integrating / Deleting of Remote Portlets protected via Portal Access Control

Questions?

Further Reading: Portal Security Whitepaper G325-2090-01http://www-128.ibm.com/developerworks/websphere/library/techarticles/0511_buehler/0511_buehler.html

Further Reading: Portal Security Whitepaper G325-2090-01http://wwwhttp://www--128.ibm.com/developerworks/websphere/library/techarticles/0511_b128.ibm.com/developerworks/websphere/library/techarticles/0511_buehler/0511_buehler.htmluehler/0511_buehler.html