“Secure Portal” or WebSphere Portal – Security with Everything
1 like3,154 views
This document discusses various methods for implementing security and single sign-on capabilities in WebSphere Portal, including authenticating against corporate directories, using LDAP for authorization and personalization, desktop single sign-on in Microsoft environments using Kerberos and SPNEGO, backend single sign-on within IBM products using LTPA tokens, and asserting identity in open environments using standards like SAML and Shibboleth. It provides high-level overviews and considerations for different security integration approaches.
Ad
More Related Content
What's hot (20)
Similar to “Secure Portal” or WebSphere Portal – Security with Everything (20)
Ad
More from Dave Hay (7)
Ad
Recently uploaded (20)
“Secure Portal” or WebSphere Portal – Security with Everything
- 1. “Secure Portal” or WebSphere Portal – Security with Everything Dave Hay Portal Architect IBM Software Services for Lotus [email protected] 18 March 2010
- 2. Agenda ● Definition of Terms ● Moving away from the “Out Of The Box” experience ● Federated Repositories ● Custom User Registry ● Authentication against a Corporate Directory ● Authorisation and Personalisation via LDAP and Property Extension Database ● Desktop Single Sign-On in a Microsoft environment ● Back-end SSO – in an all-IBM world ● Back-End SSO – Using a Reverse Web Proxy server ● Back-end SSO – Asserting identity in an open world ● Further Reading 2
- 3. Portal Operational Model (Production) Cluster Manager Web Delivery Content Server Portal Rendering Site Load Visitor Balancer Content / Portal Content / Portal Database Database Delivery Content Web Portal Authoring Server Cluster Cluster User User Directory Directory 3
- 4. Definition of Terms ● WebSphere Application Server (WAS) ● WebSphere Portal (WP) ● Authentication vs. Authorisation vs. Personalisation ● Property Extension Database ( aka LookAside ) ● Virtual Member Manager (VMM) ● WebSphere Identity Manager (WIM) ● Custom User Registry (CUR) ● Trust Association Interceptor (TAI) ● Lightweight Third Party Authentication (LTPA) ● Simple and Protected GSSAPI Negotiation Mechanism (SPNEGO) ● Security Assertion Markup Language (SAML) ● Kerberos ● Shibboleth 4
- 5. Authentication etc. 5
- 6. Moving away from the “Out Of The Box” experience ● Portal automatically secured against WAS via WIM File System Repository ● Optional during WAS installation; default during WP installation ● Provides basic identity, profile and user information ● Simple to manage via WAS/WP user interface and Java/API ● Unwieldy – all user/group management is only via WAS/WP, and not easily accessible to back-end systems without coding ● Portal security cannot “reach out” to back-end resources e.g. no SSO 6
- 7. Federated Repositories ● WAS/WP 6.1 and beyond ● Provides support for multiple user repositories, including WIM ( File System ), LDAP, databases etc. ● Useful for multiple user communities and use cases e.g. intranet and internet and extranet ● Fits well with virtualization e.g. Virtual Portal ● Needs careful planning and consideration e.g. user/group filters, realms, Single Sign-On domains,unique user identities etc. 7
- 8. Custom User Registry ● An option for authentication where requirements dictate non-LDAP approach ● Requires custom development ● Good solution for certain use cases e.g. back-end application integration, delegation of user access and management to corporate systems ● Examples of implementation include using mainframe-based application via CUR 8
- 9. Authentication against a Corporate Directory ● Supported LDAPs Lotus Domino Microsoft Active Directory Tivoli Directory Server Novell eDirectory Sun ONE Directory Server ● Supported vs. tested vs. unsupported ● Read-only vs. Read/Write ● Security Wizard ● Alternative Security Tasks ( ConfigEngine ) ● Can be used stand-alone or as part of Federated Repository solution 9
- 10. Authorisation and Personalization via LDAP and Property Extension Database ● Describe how LDAP groups and attributes can be used to provide authorisation and personalized access to portal resources ● Authorisation and Personalization can be two sides of the same coin; both can be used to change the user experience based upon external attributes ● Authorization – where can I go now I'm in the portal ? ● Personalization – what can I see ? ● Authorisation – typically related to security e.g. permissions, user groups, roles etc. ● Personalization – typically related to attributes, events, user profile choices ● Customization – typically user controlled rather than externally influenced 10
- 11. Single Sign-On 11
- 12. SSO Domain Concepts 12
- 13. Desktop Single Sign-On in a Microsoft environment ● Provides seamless SSO to users once Windows login has completed ● Requires Portal to use same Active Directory domain as user's Windows desktops ● SPNEGO is used to negotiate the authentication protocol between client and server, using Kerberos ● Works with Internet Explorer and Firefox ● Active Directory and Kerberos ( Key Distribution Centre ) needs to be configured ● WebSphere Trust Association Interceptor (TAI) provided in WAS 6.1 and beyond ● WAS needs to be configured ● User browsers need to be configured ● No longer requires front-end IIS server 13
- 15. Back-end SSO – in an all-IBM world ● Appropriate for requirements where back-end applications support the IBM Lightweight Third Party Authentication (LTPA) mechanism ● Examples include: - WebSphere Application Server WebSphere Portal Lotus Connections Lotus Domino Lotus Quickr Lotus Sametime ● LTPA token generated by server following initial successful authentication; stored as cookie in browser ● Used to provide authentication to trusted servers; those participating in the same SSO environment (DNS domain) and sharing a common LTPA private key ( encrypted ) 15
- 16. Back-End SSO – Using a Reverse Web Proxy server ● Examples are Tivoli Access Manager for e-Business (TAMeB) and Siteminder ● IBM experiences tend towards TAMeB but Siteminder info is available ● WebSEAL is the TAMeB web reverse proxy solution ● WebSEAL intercepts all requests for secured, back-end web applications ● Hides application URLs etc. from end-users increasing security ● Authentication and authorisation ( to access web app. or not ) is made in WebSEAL ● If auth/auth sucessful, WebSEAL passes request to WAS/Portal ● TAI deployed in WAS to support this delegated authentication ● Junctions ( transparent or otherwise ) created in WebSEAL for Portal ● LTPA cookie is generated by WebSEAL junction and stored in user's browser, giving onwards SSO 16
- 18. TAMeB implementation 1 An unauthenticated client issues a request. 2 WebSEAL issues an HTTP authentication challenge. 3 Client responds to challenge. 4 WebSEAL authenticated user against user registry. 5 WebSEAL modifies the Header to include (iv_creds, …) 6 Request to WAS where TAI performs authentication of tai_user 7 User credentials are extracted from header to construct a user principal. 8 WAS sends the request the Portal 9 Portal sends the Output to WebSEAL 10 WebSEAL dispatches the output to the client. 18
- 19. Back-end SSO – Asserting identity in an open world ● Requirement where SSO is required from WebSphere to an external service ● Can potentially be used in reverse using custom TAI – not supported by IBM ● Necessary to “prove” that WebSphere user has been authenticated ● Open-standard mechanism for the assertion of the user's identity, with implicit trust and security ( SAML ) ● SAML works by way of a paired set of servers – Identity Provider (IdP) and Service Provider (SP) ● Various implements of SSO via SAML including Shibboleth and Tivoli Federated Identity Manager (TFIM) ● Some entitlement to TFIM with WAS Network Deployment http://www-01.ibm.com/software/tivoli/products/federated-identity-mgr-websphere/index.html 19
- 20. Shibboleth implementation 1) The User attempts to access a Shibboleth-protected resource on the Service Provider site. 2) The User is redirected to the federation WAYF. 3) The User select his or her home institution (*Identity Provider) from the list presented by the WAYF. 4) The Identity Provider, by whatever means it deems appropriate, ensures that the User is authenticated. 5) After successful authentication, a one-time Handle (session identifier) is generated for this User session and is sent to the Service Provider. 6) The Service Provider uses the Handle to request attribute information from the Identity Provider for this User. 7) The Identity Provider, on the basis of its Attribute Release Policy, allows or denies attribute information to be made available to this Service Provider. 8) Based on the attribute information made available to it, the Service Provider allows or refuses the User access to the resource. 20
- 21. Further Reading IBM WebSphere Application Server V6.1 Security Handbook http://www.redbooks.ibm.com/abstracts/sg246316.html?Open IBM WebSphere Application Server V7.0 Security Guide http://www.redbooks.ibm.com/abstracts/sg247660.html WebSphere Portal Family Wiki http://www-10.lotus.com/ldd/portalwiki.nsf Tivoli Access Manager for e-Business http://www-01.ibm.com/software/tivoli/products/access-mgr-e-bus/ Tivoli Federated Identity Manager http://www.ibm.com/software/tivoli/products/federated-identity-mgr 21
- 22. Any Questions ? 22