Web Sphere Portal Security

Slide 1: IBM WebSphere Portal Security Concepts Omaha WebSphere Users Group Don Jones

Slide 2: 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

Slide 3: 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

Slide 4: Portal Access Control Role, role, role your boat….

Slide 5: 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)

Slide 6: 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

Slide 7: 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>

Slide 8: 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

Slide 9: 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.

Slide 10: 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

Slide 11: 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

Slide 12: 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

Slide 13: 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

Slide 14: “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

Slide 15: 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

Slide 16: Access Control Administration via Portlets

Slide 17: 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>

Slide 18: 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 >>

Slide 19: 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)}

Slide 20: 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

Slide 21: 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

Slide 22: 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

Slide 23: 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

Slide 24: 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)}

Slide 25: 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

Slide 26: 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)

Slide 27: Portal Authentication And SSO and WMM and …

Slide 28: 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

Slide 29: 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?)

Slide 30: 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”

Slide 31: 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

Slide 32: 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

Slide 33: 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

Slide 34: 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

Slide 35: 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

Slide 36: 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!!!!*

Slide 37: 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

Slide 38: 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

Slide 39: 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)

Slide 40: 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

Slide 41: Single Sign-On

Slide 42: 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

Slide 43: 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

Slide 44: 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

Slide 45: 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

Slide 46: 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

Slide 47: 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

Slide 48: 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

Slide 49: 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)

Slide 50: 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

Slide 51: 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

Slide 52: 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

Slide 53: 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

Slide 54: WSRP – A “Special” SSO case

Slide 55: 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

Slide 56: WSRP Overview § Authentication: § Submit of user profile § Support of WS-Security § SSL client authentication § Authorization: § Usage of Portal Access Control

Slide 57: 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

Slide 58: 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

Slide 59: 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

Slide 60: 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

Slide 61: 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

Slide 62: 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

Slide 63: 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

Slide 64: 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