没有合适的资源?快使用搜索试试~ 我知道了~
资源推荐
资源详情
资源评论
Portal User Management Architecture (PUMA)
sample scenarios in IBM® WebSphere® Portal
James W Barnes, WebSphere Portal API Level 2 Team Lead
Thomas Hurek, Chief Programmer, Fix Packs & Lab Services Consultant
Ryan R Wilson, WebSphere Portal API Level 2 Technical Lead
WebSphere Portal Development and Support
IBM US & Germany
September 2008
© Copyright International Business Machines Corporation 2008. All rights reserved.
Abstract. This document describes how to use Portal User Management Architecture
(PUMA) for your IBM® WebSphere® Portal implementation. Specifically, you learn how
to use a public API to implement custom scenarios with code samples, and how to
customize the existing forms and screens for custom user management. It is intended
for WebSphere Portal application developers and administrators who need to implement
custom solutions to suit the needs for individual user management.
PUMA scenarios
Contents
1 Introduction to WebSphere Portal user management ..................................................... 2
1.1 Portal User Management Architecture...................................................................... 3
1.2 Supported user registries........................................................................................... 3
1.3 User management operations.................................................................................... 4
1.4 PUMA configuration ................................................................................................ 4
1.5 WMM configuration................................................................................................. 5
1.6 PUMA programming interface................................................................................. 5
2 Implementation scenarios for PUMA............................................................................. 6
2.1 Creating a user management portlet using the PUMA SPI....................................... 6
2.2 Adding a user.......................................................................................................... 10
2.3 Editing a user .......................................................................................................... 14
2.4 Deleting a user ........................................................................................................ 15
2.5 Adding a group ....................................................................................................... 16
2.6 Deleting a group...................................................................................................... 17
2.7 Adding a member to a group .................................................................................. 18
2.8 Removing a member from a group......................................................................... 21
2.9 Customizing password expiration........................................................................... 21
2.9.1 Alternate method for retrieving the data.......................................................... 31
3 Implementation scenario: User Agreement use case..................................................... 32
3.1 User Agreement form ............................................................................................. 32
3.2 Custom Log-in portlet............................................................................................. 33
3.3 Determining whether a user has signed the agreement........................................... 36
3.3.1 SingletonUserAgreement................................................................................. 36
3.4 Redirecting the user to the Agreement page........................................................... 38
3.5 Displaying the User Agreement form in the log-in portlet..................................... 39
4 Conclusion ..................................................................................................................... 41
5 Resources....................................................................................................................... 41
6 About the authors........................................................................................................... 41
1 Introduction to WebSphere Portal user management
WebSphere Portal features a powerful user management component that lets you connect it to
various user repositories. Although these user repositories contain the actual users and groups
data, it is the Portal User Management Architecture (PUMA) component that is key to
manipulating the data in the user repositories for the users of WebSphere Portal.
We begin with an introduction to PUMA and the operations and configurations that are possible.
The main part of the paper describes how to use a public API to implement custom scenarios with
code samples, and how to customize the existing forms and screens for custom user
management.
Among the forms and screens is the User Agreement form, the Password expiration screen, and
the Self Registration/Edit Profile screens. Finally, we create a User Agreement form use case that
forces users to sign before accessing the protected pages.
To get the most from this white paper, you should have a general understanding of WebSphere
Portal administration and security setup. Although this paper focuses on version 6.0.x, the main
2
PUMA scenarios
concepts also apply to versions 5.1.0.x and 6.1.0.x. More information about WebSphere Portal
administration and the user management basics can be found in the
WebSphere Portal
Information Center.
1.1 Portal User Management Architecture
Figure 1 shows how the PUMA component fits within the WebSphere Portal architecture.
Figure 1. WebSphere Portal architecture showing PUMA
WebSphere Portal
Engine
PUMA
WebSphere
Member Manager
WebSphere
Application Server
Custom User Registry
Interface
EJB Facade
WMM Registry
Implementation
User Registry
Lookaside &
Federation DB
Authentication
User & Group Management
wmm.xml
puma.properties
Multiple Realm
Configuration
PumaService.
properties
XMLAccess
Admin UI
User management in WebSphere Portal can be performed either through the user interface
Administration portlets (for example, via the User and Groups portlet) or via the scripting interface
XMLAccess that calls the user management component for the operations.
The user management component facilitates the WebSphere Member Manager (WMM)
component as an abstraction layer to the physical user registry. WMM connects to the User
Registry and optionally to a federation and lookaside database. See the next section for details
about the supported user registries.
The configuration of the PUMA and WMM components for the different user repositories is done
via property or XML files. If multiple realms are configured, WMM is also used for the
authentication of users.
1.2 Supported user registries
WebSphere Portal supports the use of the WMM user database, a Lightweight Directory Access
Protocol (LDAP) server, or a custom user registry (CUR) as user registries. The WMM user
database stores the user and group information within the configured database system. See the
3
PUMA scenarios
WebSphere Portal detailed system requirements page for details on which LDAP servers are
supported.
A CUR is a custom implementation that might use a database or other backend systems to store
the data. After WebSphere is installed, the WMM user database is used as user registry, and
security is disabled in the WebSphere Application Server configuration. This configuration is not
recommended for production use due to security risks.
The configuration tasks enable-security-ldap or enable-security-wmmur-ldap allow you to enable
security and configuring the specified LDAP server.
The configuration task enable-security-wmmur-db enables security and configures the WMM user
database as the user registry.
1.3 User management operations
WebSphere Portal lets you perform the following user management operations:
• Users:
o Creation
Self-Enrollment: Anonymous user can create a user
o Modification of attributes (among these: password)
Selfcare: User can update his own attributes
o Deletion
• Groups:
o Creation
o Modification of attributes
o Deletion
o Adding a user to a group
o Removing a user from a group
All these operations are protected with WebSphere Portal Access Control to ensure that only
privileged users can perform the operations.
The following interfaces allow the different operations:
• XMLAccess: Does not allow Self-Enrollment.
• Administration portlets: User and Groups Portlet, Edit my Profile Portlet and Screen
• PUMA programming interface: Allows writing custom implementations that trigger user
management operations via the programming interface.
1.4 PUMA configuration
The configuration of the PUMA and the WMM components determines the effect of the user
management operations in the user repository. While the WMM component configuration is
responsible for the connection to the user repository, the PUMA component configuration
determines the way users and groups are retrieved from and stored in the user repository.
The configuration of the PUMA component is done via the PumaService.properties
(located in PortalServer/shared/app/config/services/) and puma.properties (located in
PortalServer/shared/app/config/) files. In Portal 6.0.x the configuration of the properties is handled
via the WebSphere Portal PumaService in the WAS Admin Console.
4
PUMA scenarios
1.5 WMM configuration
You must configure WMM by editing the wmm.xml, wmmAttributes.xml,
wmmLDAPServerAttributes.xml, wmmDBAttributes.xml, wmmur.xml,
and
wmmWASAdmin.xml files, all of which are stored in the Portal/wmm directory. In a cluster
environment you must be sure to first check out the files from the Deployment Manager (using the
check-out-wmm-cfg-files-from-dmgr config task), and after making the change in the Portal/wmm
directory, to check them in again (using the check-in-wmm-cfg-files-to-dmgr config task).
Here’s what the files do:
wmm.xml: Stores information about the repositories.
wmmAttributes.xml: Basic definition of the attributes supported by WMM.
wmmLDAPServerAttributes.xml: Default mapping of attributes for the LDAP server.
wmmDBAttributes.xml: Default mapping of attributes when using the database
repository.
wmmUR.xml: Contains the “realm” information.
wmmWASAdmin.xml: Defines the user base in the File local mode case (used during
startup of the server).
1.6 PUMA programming interface
WebSphere Portal Version 5.1.0.1 introduced a System Programming Interface (SPI) for
managing user profile and group membership information, called PUMA SPI. You can use it to
create, update, and delete users and groups, and to retrieve information about the current active
user. It also lets you search for users and groups in your backend repository.
The PUMA SPI consists of a Home object, available through JNDI lookup, and three service
interfaces, available through the Home object (see figure 2).
Figure 2. WebSphere Portal public PUMA SPI
PumaHome
or
PumaAdminHome
Provides Service Objects
based
3 available
PumaProfile (read)
PumaController
(read/write)
PumaLocator PumaController
PumaProfile
Available as
PortletService (JSR,
legacy)
While the PUMA SPI takes care of handling Java™ 2 Security permissions under the cover, it is
protected via WebSphere Portal Access Control. This means that the user who is accessing the
5
剩余41页未读,继续阅读
资源评论
chanlehero
- 粉丝: 4
- 资源: 25
上传资源 快速赚钱
- 我的内容管理 展开
- 我的资源 快来上传第一个资源
- 我的收益 登录查看自己的收益
- 我的积分 登录查看自己的积分
- 我的C币 登录后查看C币余额
- 我的收藏
- 我的下载
- 下载帮助
安全验证
文档复制为VIP权益,开通VIP直接复制
信息提交成功