IBM WebSphere Portal Security
Concepts
Omaha WebSphere Users Group
Don 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….

Portal Access Control
§ 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
Permission = (action, resource)
Role
User Subsystem
User
Manager@Welcome_Page
Editor@Weather_Portlet
User Group
(groups may be nested)
Permission-to-Role Role Assignment
mapping Role-to-Principal Inheritance by Group
mapping membership

Portal Access Control
§ 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 a
Portal 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 specific
child node
§ Role name is <template-name>@<resource-subtree-root>

Access Control picture
resources
User/Group registry
Page1 Page2
Portal Roles
Administrator@Portal
User@Page1
Administrator@Page1 User1
User2
Portlet User@Page2
Administrator@Page2 Group1
User@Portlet1 Group2
…
Principal-to-Role
(Appl Roles not shown) mappings
Permission-to- *Can be directly WMM MR, or user
controlled by registry
Role mappings external service,
(sets of independent of
provisioning, can
privileges on WMM groups* affect what groups
resources) a user is in
Portal DB

Portal Role Types
Administrator
Security
Manager
Administrator
Privileged
Delegator Editor
User
§ Imply/provide the “actions” of the (action, resource) tuples in a Role
§ Users are allowed to view portal resources
User
§ 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.

Protected Resource Hierarchy (simplified)
Protected Resource Hierarchy
Virtual root resource of the
Virtual root resource of the
protected resource hierarchy
protected resource hierarchy root
Virtual Resource
Virtual Resource
page root External AZN app root
Protected Resource
Protected Resource
Teller app app 2
page 1
portlet 1 portlet 2
Teller page
page 3 page 4
page 5
page 6

Role Instances
Protected Resource Hierarchy
Virtual root resource of the
Virtual root resource of the
protected resource hierarchy Administrator
protected resource hierarchy root
Virtual Resource
Virtual Resource Administrator
page root External AZN app root
Protected Resource
Protected Resource
Manager User app 2
page 1 Teller app
Inheritance Block for
Inheritance Block for
Domain Root Resource
Domain Root Resource roles of type Editor
roles of type Editor
for Editor@Teller page
for Editor@Teller page Editor
portlet 1 portlet 2
Teller page
Editor
Editor
page 3 page 4 Editor
page 5
IRBAC role instance:
IRBAC role instance:
Manager@page1
Manager@page1
page 6

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_43
wsadmin>$PacList view [$Access getacl application _2_0830M4HTFF0GHQ05_43]
PacList[_2_0830M4HTFF0GHQ05_43]
wsadmin>$PacList list User all
<< Anonymous User >>

Externalization Approach
Portal Tivoli Access Manager
Portal Admin TAM Admin
Portal Resource Topology
Tivoli
o1 Editor Access Manager
o2 o3 Editor@o1
o4 o5 o6
User Registry
Portal DB
Editor@o1
{(view,o1),...(view,o6),
(edit,01),...(edit,06)}

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 an
administrator 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

Access Control picture
resources
User/Group registry
Page1 Page2
Portal Roles
Administrator@Portal
User@Page1
Administrator@Page1 User1
User2
Portlet User@Page2
Administrator@Page2 Group1
User@Portlet1 Group2
…
Principal-to-Role
mappings
Permission
*Can be directly WMM MR, or user
-to-Role controlled by registry
mappings external service,
independent of
provisioning, can
WMM groups* affect what groups
a user is in
Portal DB

Externalization Approach (via alias)
Portal
Portal Admin YCAC Admin
Portal Resource Topology
Your Cool Access
o1 Editor Control
o2 o3 xyz
o4 o5 o6
User Registry
Portal DB
Editor@o1
Alias=xyz
{(view,o1),...(view,o6),
(edit,01),...(edit,06)}

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 to
j_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”
Login via UI,
Login via UI, Portal login
Portal login
XMLAccess,
XMLAccess,
handler
Retrieve User
Retrieve User WMM
WMM
Scripting submitted
Scripting submitted handler (portal component)
(portal component)
ID/PW
okay?
ID/PW
okay? Fetch attributes by
WAS Security API (JAAS) DN (user profile)
Fetch nested group
WAS
WAS memberships
Security
Security Independent of
WAS lookup but
based on DN from
WAS LDAP User
WAS
WAS LDAP User
Registry configuration
Registry configuration
(e.g. via admin console)
(e.g. via admin console) Portal/WMM LDAP
Portal/WMM LDAP
config (wmm.xml)
config (wmm.xml)
Search, “bind”
(validate id/pw), LDAP
LDAP
fetch DN, fetch
group memberships

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”
Login via UI,
Login via UI, Portal login
Portal login
XMLAccess,
XMLAccess,
handler
Retrieve User
Retrieve User WMM
WMM
Scripting submitted
Scripting submitted handler (portal component)
(portal component)
ID/PW
okay?
ID/PW
okay?
Search, “bind”
(validate id/pw),
fetch DN, fetch Fetch attributes by
WAS Security API (JAAS) group memberships DN (user profile)
Fetch nested group
WAS
WAS memberships
Security
Security Independent of
WAS lookup but
(WMMUR) based on DN from
WAS “Custom User
WAS
WAS “Custom User
Registry” configuration
Registry” configuration
(e.g. via admin console)
(e.g. via admin console) Portal/WMM LDAP
Portal/WMM LDAP
config (wmm.xml)
config (wmm.xml)
LDAP
LDAP

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 config
tasks 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 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”
Login dialog
Security
Security Portal and
Portal and
Login dialog
Front-end
Front-end WMM
WMM
All id/pw validation kay
ookay (portal component)
kup
(portal component)
Asserts
Identity ookup
Asserts
Identity
done by front end
lo
AS lo
WA S
W
Fetch attributes by
WAS
WAS DN (user profile)
TAI
TAI
Security
Security
Fetch nested group
memberships
(WMMUR) Independent of
WAS lookup but
based on DN from
WAS User Registry
WAS (from TAI)
WAS User Registry
configuration
configuration
(e.g. via admin console)
(e.g. via admin console) Portal/WMM LDAP
Portal/WMM LDAP
config (wmm.xml)
config (wmm.xml)
Search, fetch DN,
fetch group LDAP
LDAP
memberships

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
Config “name” WAS setup Portal/WMM setup
LDAP+Lookaside LDAPRegistryImpl Portal-supplied LDAP MR plus optional WMM
or WMMUR profile extension lookaside db (“extended
attributes”)
Application LDAPRegistryImpl Portal-supplied LDAP MR plus optional WMM
or WMMUR profile extension lookaside db (“extended
groups attributes”) plus additional WMM db holding
groups (users from LDAP)
Custom Custom Custom MemberRepository implementation
UserRegistry or under WMM – either complete or “Decorator”
WMMUR
around LDAP.
Supported but not public – requires AECI.
WMM DB only Portal-supplied WMM proprietary database (*not* your own
“WMM DB CUR” database) for users and groups
UserRegistry impl
(not WMMUR)
(No customer does this in production that I know
of)

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
Client-Web App Portal-Back End
SSO SSO
Web
Client Application Back End
Application
Client Portlet
Authentication Portal Back End
Portlet
Proxy Server Application
Client Portlet
Back End
Client Other
Application
Application

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

Portal to Backend SSO: WP Credential Vault
Not just an id/password store – that’s just the bottom layer
A Portlet Service for storing and retrieving
SSO Credentials including the user‘s JAAS Portlet Portlet Portlet
Subject that was built during login.
+
Credential Portlet Service
A vault adapter interface to integrate vault Vault Adapter Interface
Adapter
implementations like the Tivoli Access
Adapter
Adapter
Custom
Default
TAM
Manager Global Sign-On Lockbox
Encryption
+ Exit
A basic vault implementation (the default
credential store) Default TAM GSO
Vault Impl. Lockbox
+
An Encryption Exit for the basic vault Custom
implementation (default impl is Base64) Vault

WP Credential Vault Structure
§ Vault Segments contain Vault Slots
§ Vault Slots represent the credentials Vault Segment U Vault Segment A1 Vault Segment A2
for one or more users
Slot a Slot b Slot c Slot x Slot y
§ Segments (and Slots in them) either
user managed or administrator
managed
Vault Vault Vault
Adapter Adapter Adapter
§ Slot types:
§ System Credential Slot (administrator
managed): System wide Credentials
Vault
§ Shared Credential Slot (user managed): Implementations
User specific, accessible by all Portlets Internal External
§ Portlet Private Slot (user managed):
User and Portlet specific

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
Portal
Portal 5. Send Business Request
Portlet API
Portlet
Portlet Backend System
Backend System
Engine
Engine
3. Get Connection
4. Authenticate
Credential
1. Retrieve
Active
Active
Credential
Credential
Credential Vault
Credential Vault
Portlet Service 2. Retrieve Secret
Portlet Service
Vault Store

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 Websphere Portal
Portlets (WSRP) Application and
§ Industry standard for Local Content Providers
presentation oriented Web Portlets
WSRP
Services (JSR 168
Local
Local
WPS 4.x)
Portlets
Portlets
§ Spec Lead: IBM
3rd Party Content/
§ Included since WPS 5.0.2 Application Provider
Portal
Portlet API
WSRP
§ Producer Side: Portlets can be WSRP
Generic
provided as WSRP Services Internet/ Services
WSRP
Portlet Internet/ WSRP
Proxy Intranet Services
§ Consumer Side: Intranet Services
§ Setup Producer entity
§ Integrate WSRP Services in form of
Portlets from a Producer
Publish/Find Web Services (SOAP)
UDDI Registry

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 tokens
SAML 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
SOAP HEADER SOAP BODY
BinaryToken containing LTPA token Request Data
LTPA token Common LDAP
Browser Consumer User registry
/ Producer
LTPA domain
SOAP HEADER SOAP BODY
Response Data

Outlook WS-Security
Federation
Layer
WS-SecureConversation WS-Federation WS-Authorization
WS-Policy
Policy
Layer
WS-PolicyFramework WS-Trust WS-Privacy
WS-PolicyAttachments WS-PolicyAssertions
WS-Security Today
Time
SOAP Foundation

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-01
Further Reading: Portal Security Whitepaper G325-2090-01
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0511_buehler/0511_buehler.html
http://www- 128.ibm.com/developerworks/websphere/library/techarticles/0511_buehler/0511_buehler.html
http://www-128.ibm.com/developerworks/websphere/library/techarticles/0511_buehler/0511_buehler.html