| Download Docs | Site Map | Glossary | |
|
|
|||
| bea.com | products | dev2dev | support | askBEA |
|
|
|
|||||||
 |
| e-docs > WebLogic Platform > WebLogic Portal > Development Guide > Adding Security to a Portal |
|
Development Guide
|
Adding Security to a Portal
A Web server authenticates users and determines which resources within the server users can create, access, or modify. To do this, the Web server uses a security realm. When a user attempts to access a particular resource, the server tries to authenticate and authorize that user by checking the access control list (ACL) and permissions that are assigned to the user within the realm. You can set up multiple security realms, but each instance of a Web server can use only one realm. The server uses the same security realm for your Web site developers and for your visitors.
This section contains information on the following subjects:
Implementing Portal Security
If you choose to use the basic implementation of the RDBMS security realm supplied by BEA, it will be available when you install WebLogic Portal. No further configuration is necessary.
Note: The WebLogic Portal RDBMS Realm is a different implementation than the WebLogic Server RDBMS Realm. The WebLogic Server RDBMS Realm is for testing and is not suitable for use in a production environment. WebLogic Portal's RDBMS realm is shipped in the BEA_HOME/weblogic700/portal/lib/p13n_system.jar file and the implementing class is in com.bea.p13n.security.realm.RDBMSRealmas configured with the config.xml file entry: RealmClassName="com.bea.p13n.security.realm.RDBMSRealm.
Integrating with an LDAP Security Realm
If you don't want to use the basic RDBMS security realm, one popular alternative is to use a lightweight directory access protocol (LDAP) server as your security realm. This section describes how to integrate an LDAP server with WebLogic Portal. This section includes the following topics:
Supported LDAP Servers
WebLogic Portal supports these LDAP servers:
You can find templates for each of these services in Supported Server Templates.
Integrating an LDAP Security Realm
This section shows how WebLogic Portal integrates with a third-party LDAP security realm; security realms are the method used by WebLogic Portal to authenticate users. While WebLogic Portal provides a default user store based on a RDBMS, this can be replaced with an LDAP realm, which uses an LDAP server for security information.
Configuring the LDAP Server for Integration
Configuring the LDAP security realm involves defining attributes that enable the LDAP Security realm in WebLogic Server to communicate with the LDAP server and the attributes that describe how users and groups are stored in the LDAP directory. The LDAP tree and schema is different for every LDAP server.
In Supported Server Templates, you can find templates for the supported LDAP servers. These templates specify default configuration information used to represent users and groups in each of the supported LDAP servers. You choose the template that corresponds to the LDAP server you want to use and then fill in the attributes described in Table 7-1.
Note: In LDAP V1, you can configure these attributes from the LDAP Realm Create screen, on the tab specified in Table 7-1.
For instructions for configuring the LDAP security realm, please refer to "Configuring the LDAP Security Realm" in the WebLogic Server Administration Guide at http://download.oracle.com/docs/cd/E13222_01/wls/docs61/adminguide/cnfgsec.html#1052314. In addition to defining attributes that enable communication with the LDAP server, you will have to define certain groups in your LDAP server to correspond to the security role mappings that have been set for portal delegated administration. To set these groups up you should:
Configuring LDAP-based Security Realms for WebLogic Server and Portal 7.0
Perform the following steps for configuring LDAP-based security realms for WebLogic Server 7.0 and WebLogic Portal 7.0.
WebLogic Server Setup
WebLogic Portal Setup
Supported Server Templates
Listing 7-1 through Listing 7-4 are the templates you can use to configure supported LDAP servers. You can copy these templates from here directly into the config.xml file for your application.
Warning: Each line in the following code examples must appear on a single line. The examples shown below have been formatted to fit the margins of this document and some lines have been broken to facilitate that formatting. If you paste this text into the config.xml file, be sure to concatenate the lines that are broken so that they appear on a single line in your code.
Listing 7-1 Default Netscape Customer Security Realm Template
<CustomRealm
Name="defaultLDAPRealmForNetscapeDirectoryServer"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
Password="*secret*"
ConfigurationData="server.host=ldapserver.example.com;server.principal=uid=
admin,
ou=Administrators, ou=TopologyManagement, o=NetscapeRoot;user.dn=ou=people,
o=beasys.com;user.filter=(&(uid=%u)(objectclass=person));group.dn=
ou=groups,
o=beasys.com;group.filter=(&(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&(uniquemember=%M)(objectclass=
groupofuniquenames));"
Notes="This is provided as an example. Before enabling this Realm, you must
edit the configuration parameters as appropriate for your environment."
/>
Listing 7-2 Default Microsoft Customer Security Realm Template
<CustomRealm
Name="defaultLDAPRealmForMicrosoftSiteServer"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
Password="*secret*"
ConfigurationData="server.host=ldapserver.example.com;server.principal=cn=
Administrator,
ou=Members, o=ExampleMembershipDir;user.dn=ou=Members,
o=ExampleMembershipDir;user.filter=(&(cn=%u)(objectclass=member));
group.dn=ou=Groups,
o=ExampleMembershipDir;group.filter=(&(cn=%g)(objectclass=mgroup));
membership.scope.depth=1;microsoft.membership.scope=sub;membership.
filter=(|(&(memberobject=%M)(objectclass=memberof))
(&(groupobject=%M)(objectclass=groupmemberof)));"
Notes="This is provided as an example. Before enabling this Realm,
you must edit the configuration parameters as appropriate for your
environment."
/>
Listing 7-3 Default Novell Customer Security Realm Template
<CustomRealm
Name="defaultLDAPRealmForNovellDirectoryServices"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
Password="*secret*"
ConfigurationData="server.host=ldapserver.example.com;server.principal=cn=
admin,
o=example.com;user.dn=ou=people,
o=example.com;user.filter=(&(cn=%u)(objectclass=person));group.dn=ou=
groups,
o=example.com;group.filter=(&(cn=%g)(objectclass=groupofuniquenames));
membership.filter=(&(member=%M)(objectclass=groupofuniquenames));"
Notes="This is provided as an example. Before enabling this Realm, you must
edit the configuration parameters as appropriate for your environment."
/>
Listing 7-4 Default OpenLDAP Security Realm Template
<CustomRealm
Name="defaultLDAPRealmForOpenLDAPDirectoryServices"
RealmClassName="weblogic.security.ldaprealmv2.LDAPRealm"
Password="*secret*"
ConfigurationData="server.host=ldapserver.example.com;server.principal=cn=
Manager,
dc=example, dc=com;user.dn=ou=people, dc=example,
dc=com;user.filter=(&(uid=%u)(objectclass=person));group.dn=ou=groups,
dc=example,
c=com;group.filter=(&(cn=%g)(objectclass=groupofuniquenames));membership.
filter=(&(uniquemember=%M)(objectclass=groupofuniquenames));"
Notes="This is provided as an example. Before enabling this Realm, you must
edit the configuration parameters as appropriate for your environment."
/>
Using Wildcards for User Lookup in an LDAP Realm
This change has been implemented to allow true wildcard searches of the LDAP server when using the weblogic.security.ldaprealmv2.LDAPRealm.
The original implementation used a getUsers() method that did a search for uid=* and returned all users. The enumeration of all users was iterated through to find matches to the search string input in the WebLogic Portal Administration Tools.
The new implementation does a true wildcard search by using a new getUsers(String searchString, int maxResults) method that is implemented by extending the original LDAPRealm with a new com.bea.p13n.security.realm.PortalLDAPRealm.
The original WebLogic Portal Administration Tools used the CachingRealm.getUsers() method to conduct a search that returned all users in the LDAPRealm. They used a search filter that looked like this:
(&(uid=*)(objectclass=person))
This search result (all users in the realm) was iterated through and users with names that matched a wildcard search expression in the request were put into a list and were displayed as links on the page.
The new PortalLDAPRealm.getUsers(String searchString, int maxResults) method allows a true wildcard search of the LDAP server, using a search filter that looks like this:
(&(uid=a*)(objectclass=person))
Your search String is used in the (uid=...) expression in the filter. To use this patch, the <CustomRealm> is configured to use a RealmClassName of com.bea.p13n.security.realm.PortalLDAPRealm instead of weblogic.security.ldaprealmv2.LDAPRealm.
Warning: A wildcard LDAP search can be a slow operation for a large LDAP server. This is not a characteristic of WLS or Portal. This is a characteristic of LDAP and the libraries used to search it. LDAP servers populated with millions of users can be very slow for wildcard searches. To verify expected response times for wildcard searches with your system you could use an ldapsearch utility to measure a typical wildcard search, like "a*". For example, for the iPlanet Directory Server you could type something like this on one line:
ldapsearch -b "ou=People, dc=beasys, dc=com"
-D "uid=admin, ou=Administrators, ou=TopologyManagement,
o=NetscapeRoot"
-h myserver.mydomain.com -p 389 -s sub -w password -z100
"(&(uid=a*)(objectclass=person))"
A fast alternative is to use a specific user id as the search string. With a user population of millions of users, an LDAP search for uid=a* will typically be timed out by your LDAP server while a search for the specific uid=administrator will be very fast. The new PortalLDAPRealm, with its getUsers(String searchString, int maxResults) method allows you to either search with a wildcard (slow) or with an exact username (fast).
Recommendations for Using this Patch with a Large LDAP Server
Use the WLS console: CompatibilitySecurity > CachingRealm > yourCachingRealm > Configuration > Groups > GroupMembershipCacheTTL (set it to 0).
The disabling of this cache is allowed by this patch because the changes to the weblogic.security.ldaprealmvw.LDAPRealm include the changes made in in CR090409 to allow disabling of the GroupMembershipCache.
Adding User Profile Information to LDAP Users
The LdapRealm security realm and the LdapPropertyManager unified user profile (UUP) for retrieving user properties from LDAP are independent of each other. They do not share configuration information and there is no requirement to use either one in conjunction with the other. A security realm has nothing to do with a user profile. A security realm provides user/password data, user/group associations, and group/group associations. A user profile provides user and group properties. A password is not a property.
For information on setting up UUP and retrieving user profile properties for LDAP users, see Implementing User Profiles.
Switching to a WebLogic 7.0 Security Framework Security Realm
WebLogic Portal 7.0 Service Pack 4 adds support for the WebLogic Security Framework introduced in WebLogic Server 7.0. This enables the replacement of WebLogic Server 6.x security realms with WebLogic Server 7.0 realms. Prior to 7.0 SP4 WebLogic Portal 7.0 users were restricted to using the Compatibility Realm.
Even if you are using a new WebLogic Server 7.0 realm, it is possible to continue using users and groups from a Compatibility RDBMS Realm by using the RDBMSAuthenticator. Alternatively, you can use the LDAP data store embedded with WebLogic Server, or a commercial LDAP provider such as Iplanet, or a custom authentication provider that you have developed.
Setup depends on which authentication provider you use:
As of WebLogic Portal 7.0 Service Pack 4, you can also use multiple authentication providers. However, there are some limitations. See Multiple Authentication Providers Support in WebLogic Portal 7.0 SP4" on page 7-22.
In WebLogic 7.0 the security Mbeans are in binary form in the <domain>/userConfig directory. During these exercises you can check your security Mbeans by using the WebLogicMBeanDumper:
java weblogic.management.commo.WebLogicMBeanDumper -includeDefaults -name Security:* mbean_security.out
Upgrading a Portal from Compatibility Security to WebLogic Server 7.0 Security With RDBMS
This is the recommended option if you already have users and groups in an existing RDBMS security realm, such as the one that shipped with WebLogic 7.0 SP2 and earlier. By retaining user and group information in your RDBMS data store, you can avoid migrating it to an LDAP data store. The RDBMS security realm provides a high-performance, robust solution.
These instructions explain how to use a WebLogic Server 7.0 realm with users and groups from a WebLogic Server 6.x RDBMS Compatibility realm. Users and groups will be stored in a previously used Compatibility Realm.
Core Groups required for WebLogic Portal
When using the RDBMS Authenticator, there are no additional steps required in order to use WebLogic Portal applications. The core groups required for the proper operation of WebLogic Portal are pre-populated in the PointBase database that ships with WebLogic Portal, or are created during the steps for Switching to Other Databases in the Administration Guide.
Running the WLP Samples
When using the RDBMS Authenticator, there are no additional steps required in order to use the WebLogic Portal sample applications. The users and groups required for the sample applications are pre-populated in the PointBase database that ships with WebLogic Portal, or are created during the steps for Switching to Other Databases in the Administration Guide.
Upgrading a Portal from Compatibility Security to WebLogic Server 7.0 Security with Embedded LDAP
This is the recommended option if you have other applications that use the embedded WebLogic Server LDAP data store and you would like to share user and group information with a WebLogic Portal application.
These instructions explain how to upgrade from the WebLogic Server 7.0 default Compatibility RDBMS Realm to the Default Authenticator. Users and groups will be stored in the LDAP data store that is embedded in WebLogic Server.
It is essential to create the proper users and groups. If this is not done, the server will fail to start and a java.lang.SecurityException: Authentication denied message will appear in the console. If you do encounter this error, remove the entire userConfig directory, which is located under your domain directory, then restart the configuration procedure. Users and groups created in the embedded LDAP server will not be lost if you do not delete the staging directory. The staging directory is the directory that is named after your server and is used for 2-phase deployment in the internal LDAP server.
Notice the server will start with myrealm from now on. See the <Notice> in weblogic.log for <Security initializing using realm myrealm>. If the server fails to start due to an authenticator misconfiguration, you can switch back to the Compatibility Realm by removing the userConfig subdirectory under your domain directory, then restarting the server. You must then restart the configuration procedure. Users and groups created in the embedded LDAP server will not be lost if you do not delete the staging directory. The staging directory is the directory that is named after your server and is used for 2-phase deployment and the internal LDAP server.
Upgrading a Portal from Compatibility Security to WebLogic Server 7.0 Security with a Commercial LDAP Provider
This is the recommended option if you would like to capitalize on a third-party LDAP provider that you already use.
These instructions explain how to upgrade from the 7.0 default Compatibility RDBMS Realm to an Authenticator backed by a commercial LDAP server, such as the IPlanet Authenticator. Users and groups will be stored in a commercial LDAP server.
It is essential to create the proper users and groups. If this is not done, the server will fail to start and a java.lang.SecurityException: Authentication denied message will appear in the WebLogic Server administration console. If you do encounter this error, remove the entire userConfig directory, which is located under your domain directory, then restart the configuration procedure.
In addition, add the following users and groups, making the users members of the appropriate groups. Note that some groups were created in the previous step. Notice also that some users belong to multiple groups.
Notice the server will start with myrealm from now on. See the <Notice> in weblogic.log for <Security initializing using realm myrealm>. If the server fails to start due to an authenticator misconfiguration, you can switch back to the Compatibility Realm by removing the userConfig subdirectory under your domain directory, then restarting the server. You must then restart the configuration procedure.
Multiple Authentication Providers Support in WebLogic Portal 7.0 SP4
The WebLogic Portal user and group management framework communicates with only one authentication provider for basic user and group operations. Therefore, it is required that a system property be set to specify which authentication provider to use when the WebLogic Server is configured with multiple Authentication Providers.
How WebLogic Portal 7.0 uses the WebLogic Server Security Framework
WebLogic Portal 7.0 relies completely on WebLogic Server for login authentication. For authorization, WebLogic Portal has its own user and group management framework for some user/group management operations. WebLogic Portal's Delegated Administration framework uses the user and group management framework and entitlements framework for authorization. The Delegated Administration framework is not based on JAAS authorization so it does not use an authorization provider.
Limited Support of Multiple Authentication Providers in WebLogic Portal 7.0 SP4
The WebLogic Portal Administration Tools can use only one authentication provider. By default, if you have configured multiple providers, the WebLogic Portal Administration Tools use the authentication provider that is "most capable" in terms of offered functionality. However, you can force the WebLogic Portal Administration Tools to use a specific authentication provider by specifying the following system property:
com.bea.p13n.usermgmt.AuthenticationProviderName=<provider_display_name>
The system property is specified as a java -D switch on the command line for starting the server.
Users from non-specified providers can log in to the portal and personalize their portal just like a user from an external custom security realm could do with the old WebLogic Server 6.x style of security.
Resetting of user passwords using the WebLogic Portal UserManager EJB (which is used by the um [user management] JSP tag library) only works for users who are available from the specified provider, because the Portal UserManager is only aware of a single authentication provider.
Group membership used by a portal should be consistent across providers. For example, if user1 is in Group1, and Group1 is associated with the Group1 group portal, then user1 should belong to Group1 in all providers, otherwise the user may not be able to access the proper group portal if he is authenticated with a provider that does not have this group membership set up.
What Is Not Supported for Multiple Authentication Providers in WebLogic Portal 7.0 SP4
The use of multiple authentication providers with WebLogic Portal 7.0 SP4 has a larger impact on the WebLogic Portal Administration Tools than on the portal application itself. The following limitations exist:
Other Supported Security Realms
In addition to LDAP, WebLogic Server supports these security realms:
This security realm uses Windows NT account information to authenticate users. Users and groups defined through Windows NT can be used by your Web application. You can use the WebLogic Server Administration Console to view this realm, but you must use the facilities provided by Windows NT to define users and groups.
A UNIX security realm executes a native program, wlauth, to authenticate users and groups using UNIX login IDs and passwords. On some UNIX platforms, wlauth uses a Pluggable Authentication Module (PAM) that allows you to configure authentication services in a UNIX platform without altering applications that use those services. On UNIX platforms for which PAM is not available, wlauth uses the standard login mechanism, including shadow passwords when they are supported. You can use the Administration Console to view this realm, but you must use the facilities provided by the UNIX platform to define users and groups.
When you start the server, the File realm creates user, group, and ACL objects from properties defined through the WebLogic Server Administration Console and stores them in the fileRealm.properties file.
Note: The File realm is designed for use with 10,000 or fewer users. If you have more than 10,000 users, use an alternate security realm.
Enabling Secure Sockets Layer Security
The Webflow and Pipeline mechanisms that direct the presentation and business logic associated with WebLogic Portal's Commerce JSP templates make use of the Secure Sockets Layer (SSL) and declarative transport mechanisms. Links that invoke protected JSP files, as well as certain Input Processors and Pipelines, need to be accessed via the HTTPS protocol. There are a number of these links already defined in the Commerce (wlcs) Web application's web.xml deployment descriptor. Secured JSP templates that rely on SSL also require a setting in the web.xml file that indicates the transport guarantee. This guarantee can be CONFIDENTIAL or INTEGRAL.
See Setting Up Portal Navigation for information on Webflows and Pipelines.
Note: For SSL connections to work, you must have a valid SSL certificate from a certificate authority set up on your server.
config.xml Requirements for SSL
To enable SSL for your Web application, you need to ensure that the domain's config.xml file has SSL enabled, as shown in Listing 7-5.
Listing 7-5 Enabling SSL in the config.xml File
<server>
.
.
.
<SSL Enabled="true" ListenPort="7502" Name="portalServer"
ServerCertificateChainFileName="ca.pem"
ServerCertificateFileName="democert.pem"
ServerKeyFileName="demokey.pem"/>
</server>
The SSL attribute should also identify the necessary certificate filenames, the server key filename, and the server name.
config.xml is stored in <BEA_HOME>/user_projects/<YOUR_DOMAIN>.
where <YOUR_DOMAIN> is the domain folder created when you ran the Configuration Wizard.
web.xml Requirements for SSL
You must also ensure that the secure listening ports in the Web application's deployment descriptor (web.xml) match that set in config.xml, as shown in Listing 7-6.
Listing 7-6 Identifying Listen Ports
Enabling HTTPS_URL_PATTERNS
Enabled HTTPS_URL_PATTERNS for portal pages (the CreatePageChangeURLTag tag) as decribed above. The entries have the form /groupPortalDisplayName/pageName. If the user is not authenticated, the group portal name will be "DEFAULT_GROUP_PORTAL" so if you wish to specify that the page change URL for a page called "home" uses HTTPS when no one is logged in specify /DEFAULT_GROUP_PORTAL/home in the HTTPS_URL_PATTERNS section of web.xml
Example:
<context-param>
<param-name>HTTPS_URL_PATTERNS</param-name>
<param-value>
/framework/security/login.jsp,
/framework/security/new_user.jsp,
/security/NewUser.inputprocessor,
/security/LoginIP.inputprocessor,
/groupPortal1/page1,
/groupPortal2/page1
</param-value>
</context-param>
Also added a FORCE_HTTPS_FOR_AUTH_USERS option to web.xml. This will cause all CreateWebflowURLTag derived tags to generate https URLs if the user has been authenticated and the tag is not specifically coded to use http. The web.xml entry should be as follows, with value true to enable the feature and false to turn it off.
<context-param>
<param-name>FORCE_HTTPS_FOR_AUTH_USERS</param-name>
<param-value>true</param-value>
</context-param>
If the FORCE_HTTPS_FOR_AUTH_USERS is enabled but the user is not logged in the HTTPS_URL_PATTERNS will be checked. If FORCE_HTTPS_FOR_AUTH_USERS is enabled and the user is logged in HTTPS_URL_PATTERNS are ignored and all URLs will be https unless the tag has been specifically coded for http.
See Enabling HTTPS_URL_PATTERNS" on page 7-27 for more information.
Enabling Single Sign-On
With single sign-on enabled, a visitor needs only to sign-on once to access multiple web applications, provided those applications are running on the same server or cluster. Enabling single sign-on requires these steps:
Setting the Cookie Name
Set the cookie name for each application to which the visitor will have single sign-on access. To do this, edit the weblogic.xml file located in <BEA_HOME>weblogic700\ samples\portal<PORTAL_DOMAIN>\beaApps\<PORTAL_APP>\<PORTAL>\WEB-INF\ for each application to which the visitor will have single sign-on access.
Listing 7-7
<session-param>
<param-name>CookieName</param-name>
<param-value>JSESSIONID_SAMPLEPORTAL</param-value>
</session-param>
Setting the User Properties
Each Web application to which a visitor has single sign-on access must use the same user property sets for the specific visitor. You will need to ensure this by editing these property sets and making them match. For details on editing user property sets, see Creating a Property Set Definition.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
