• No results found

Security – Configuring Single Sign-On

In document Oracle Application Server 10g (Page 97-99)

modify the virtual host information by selecting a virtual host from the Virtual Hosts section on the HTTP Server Home Page.

Security – Configuring Single Sign-On

To enable Oracle Application Server Single Sign-On to work with an OracleAS Cluster, the Single Sign-On server needs to be aware of the entry point into the cluster, which is commonly the load balancing mechanism in front of the Oracle HTTP Servers. This mechanism could exist as Oracle Application Server Web Cache, a network load balancer appliance, or an Oracle HTTP Server installation.

In order to register an OracleAS Cluster’s entry point with the Single Sign-On server, use the SSORegistrar tool, which can be executed through ossoreg.jar.

In order to participate in Single Sign-On functionality, all Oracle HTTP Server instances in a cluster must have an identical Single Sign-On registration. ■ Each Oracle HTTP Server is registered with the same Single Sign-On server. ■ Each Oracle HTTP Server redirects a success, logout, cancel, or home message to

the public network load balancer. In a clustered environment, each Oracle HTTP Server should redirect message URLs to the network load balancer. Since the client cannot access an Oracle HTTP Server directly, the client interacts with the network load balancer.

As with all cluster-wide configuration information, the Single Sign-On configuration is propagated among all Oracle HTTP server instances in the cluster. However, the initial configuration is manually configured and propagated. On one of the application server instances, define the configuration with the ossoreg.jar tool. Then, DCM propagates the configuration to all other Oracle HTTP Servers in the cluster.

If you do not use a network load balancer, then the Single Sign-on configuration must originate with whatever you use as the incoming load balancer— Oracle Application Server Web Cache, Oracle HTTP Server, and so on.

To configure a cluster for Single Sign-On, execute the ossoreg.jar command against one of the application server instances in the cluster. This tool registers the Single Sign-On server and the redirect URLs with all Oracle HTTP Servers in the cluster. Run the ossoreg.jar command with all of the options as follows, substituting information for the italicized portions of the parameter values.

The values are described fully in Table 4–5.

■ Specify the host, port, and SID of the database used by the Single Sign-On server. ■ Specify the host and port of the front-end load balancer in mod_osso_url

parameter. This should be a HTTP or HTTPS URL depending on the site security policy regarding SSL access to OracleAS Single Sign-On protected resources. ■ Specify the root user of the host that you are executing this tool on in the -u option. $ORACLE_HOME/jdk/bin/java -jar $ORACLE_HOME/sso/lib/ossoreg.jar

-oracle_home_path <orcl_home_path> -site_name <site_name> -config_mod_osso TRUE -mod_osso_url <URL> -u <userid> [-virtualhost <virtual_host_name>] [-update_mode CREATE | DELETE | MODIFY] [-config_file <config_file_path>] [-admin_info <admin_info>]

Security – Configuring Single Sign-On

[-admin_id <adminid>]

Table 4–5 SSORegistrar Parameter Values

Parameter Value

oracle_home_path

<orcl_home_path>

Absolute path to the Oracle home of the application server instance, where you are invoking this tool.

site_name <site_name> Name of the sitetypically, the effective host name and port of the partner application. For example,

application.mydomain.com.

config_mod_osso TRUE If set to TRUE, this parameter indicates that the application being registered is mod_osso. You must include config_mod_ osso for osso.conf to be generated.

mod_osso_url <URL> The effective URL of the partner application. This is the URL that is used to access the partner application. The value should be specified in this URL format:

http://oracle_http_host.domain:port

u <userid> The user name that will start the Oracle HTTP Server. In UNIX,

this name is usually "root." On Windows NT/2000, it is

SYSTEM. The parameter u is mandatory.

virtualhost <virtual_ host_name>

Optional. Use this parameter only if registering an Oracle HTTP virtual host with the OracleAS Single Sign-On server. If you create a virtual host, be sure, in the httpd.conf file, to fill in the following directive for each protected URL:

<VirtualHost host_name> OssoConfigFile $ORACLE_ HOME/Apache/Apache/conf/osso/host_ name/osso.conf OssoIpCheck off #<Location /your_protected_url> # AuthType basic # Require valid-user #</Location>

#Other configuration information for the virtual host </VirtualHost>

The commented lines must be uncommented before the application is deployed.

update_mode CREATE | DELETE | MODIFY

Optional. Creates, deletes, or modifies the partner registration record. CREATE, the default, generates a new record. DELETE

removes the existing record. MODIFY deletes the existing record and then creates a new one.

config_file <config_ file_path>

Optional. Location of the osso.conf file for the virtual host if one is being configured. It may, for example, be $ORACLE_ HOME/Apache/Apache/conf/osso/virtual_host_ name/osso.conf.

Note that the osso.conf for the non-virtual host is located at

$ORACLE_HOME/Apache/Apache/conf/osso.

admin_id <name> (Optional) User name of the mod_osso administrator. This shows up in the Single Sign-On tool as contact information.

admin_info <text> (Optional) Additional information about the mod_osso

administrator, such as e-mail address. This shows up in the Single Sign-On tool as contact information.

In document Oracle Application Server 10g (Page 97-99)