Part II Configuring the Secure Remote Access Server
Most attributes can be set using the options available under the Secure Remote Access tab in the Portal Server management console. Any new organization or user that is created inherits these values, by default.
You can configure the attributes related with Secure Remote Access at the organization, role, and user levels, with the following exceptions:
-
Conflict Resolution Level cannot be set at the user level. See Setting Conflict Resolution.
-
MIME types Configuration File Location attribute can be set only at the organization level.
Values set at the level of an organization are inherited by all the roles and users under it. Values set at the user level override the values set at the organization or role levels.
You can make changes to the attribute values at the Service Configuration level. These new values are reflected only when new organizations are added.
This section has the following chapters:
-
Chapter 7, Configuring the Secure Remote Access Server Access Control
-
Chapter 12, Configuring Netlet With Private Domain Certificates
Chapter 7 Configuring the Secure Remote Access Server Access Control
This chapter describes allowing or denying access to the users from the Sun Java System Portal Server administration console.
Configuring Access Control
You can specify the list of URLs that end users cannot access through the Gateway using this field. The Gateway checks the Denied URLs list before checking the Allowed URLs list.
You can specify all the URLs that can be accessed by the end user through the Gateway. By default, this list has a wild card entry (*), which means that all URLs can be accessed. If you want to allow access to all URLs, and restrict access only to specific URLs, add the restricted URLs to the Denied URL list. In the same way, if you want to allow access only to specific URLs, leave the Denied URLs field blank, and specify the required URLs in the Allowed URLs field.
The Access Control service in SRA software allows you to control the single sign-on feature for various hosts. For the single sign-on feature to be available, the Enable HTTP Basic Authentication option in the Gateway service must be enabled..
With the Access Control service, you can disable single sign-on for certain hosts. This means that an end user needs to authenticate each time to connect to the hosts that require HTTP basic authentication, unless you enable single sign-on per session.
If you have disabled single sign-on for a certain host, the user can reconnect to that host within a single Portal Server session. For example, assume that you have disabled single sign-on to abc.sesta.com. The first time the user connects to this site, authentication is required. The user may browse other pages and return to this page later, and if the page is in the same Portal Server session, authentication is not required.
To Configure the Access Control
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab.
-
Select the Access Control tab.
-
Modify the following attributes:
Attribute Name
Description
COS Priority
Specifies the value used to determine the inheritance of the attribute value. For more information on this attribute, see the Sun Java System Directory Server Administration Guide.
Single Sign On per Session
Select the Enable checkbox to enable a single-sign on session.
Single Sign On Disabled Hosts
Enter the host name in the format abc.siroe.com.
Allowed Authentication Levels
Enter the allowed authentication levels. Use an asterisk to allow all levels. The default value is asterisk.
Allow/Deny access to URL's
Enter the URL to allow or deny access through the Gateway in the in the URL field. The format for entering the URL is: http://abc.siroe.com. Under Action drop down list, click the appropriate Allow or Deny option.
You can also use regular expressions such as http://*.siroe.com. In this case, users are denied access to all hosts in the siroe.com domain.
The Gateway first checks the URLs that have been denied access before checking the allowed URLs list.
Note –The Allowed URLs field has a * by default which means that all URLs can be accessed through the Gateway.
Note –When you install SRA, the Access Control l service is not available to all users by default. This service is enabled only to the amadmin user that is created by default during installation. Other users cannot access the desktop through the Gateway without this service. Log in as amadmin, and assign this service to all the users.
-
Click Save to complete.
Chapter 8 Configuring the Secure Remote Access Gateway
This chapter describes configuring the Gateway attributes from the Sun Java System Portal Server administration console.
This chapter contains the following sections:
Before you Begin
-
To create a gateway profile, see Creating a Gateway Profile
Configuring the Profile Core Options
This section explains the following tasks:
Configuring the Startup Mode
The Gateway runs in HTTPS mode after installation if you have chosen to run the Gateway in the HTTPS mode during installation. In the HTTPS mode, the Gateway accepts SSL connections from browsers and rejects non-SSL connections. However, you can also configure the Gateway to run in HTTP mode. This speeds Gateway performance as the overhead involved in managing SSL sessions and encrypting and decrypting the SSL traffic are not involved.
To Configure the Startup Mode
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab, and click the profile name to modify its attributes.
-
Select the Core tab.
-
Modify the following attributes:
- HTTP Connections
-
Select the HTTP Connections checkbox to allow Gateway to accept non-SSL connections.
- HTTP Port
-
Enter the HTTP port number. The default value is 80.
- HTTPS Connections
-
Select the HTTPS Connections checkbox to allow Gateway to accept SSL connections. By default, this options is selected.
- HTTPS Port
-
Enter the HTTPS port number. The default value is 443.
Note –The following attributes can be modified using psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
/space/PS/portal/bin/psadmin set-attribute -u amadmin -f /space/PS/portal/bin/ps_password -p portal1 -m gateway --gateway-profile profileID -a sunPortalGatewayDomainsAndRulesets -A $entry
-
sunPortalGatewayDefaultDomainAndSubdomains=Default Domains
-
sunPortalGatewayLoggingEnabled=Enable Logging
-
sunPortalGatewayEProxyPerSessionLogging=Enable per Session Logging
-
sunPortalGatewayEProxyDetailedPerSessionLogging=Enable Detailed per Session Logging
-
sunPortalGatewayNetletLoggingEnabled=Enable Netlet Logging
-
sunPortalGatewayEnableMIMEGuessing=Enable MIME Guessing
-
sunPortalGatewayParserToURIMap=Parser to URI Mappings
-
sunPortalGatewayEnableObfuscation=Enable Masking
-
sunPortalGatewayObfuscationSecretKey=Seed String for Masking
-
sunPortalGatewayNotToObscureURIList=URIs not to Mask
-
sunPortalGatewayUseConsistentProtocolForGateway=Make
-
Gateway protocol Same as \n Original URI Protocol sunPortalGatewayEnableCookieManager=Store External Server Cookies
-
sunPortalGatewayMarkCookiesSecure=Mark Cookies as secure
-
Restart the Gateway from a terminal window:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
Configuring the Core Components
Netlet enables users to securely run common TCP/IP services over insecure networks such as the Internet. You can run TCP/IP applications (such as Telnet and SMTP), HTTP applications, and any fixed port applications. If Netlet is enabled, the Gateway needs to determine whether the incoming traffic is Netlet traffic or Portal Server traffic. Disabling Netlet reduces this overhead since the Gateway assumes that all incoming traffic is either HTTP or HTTPS traffic. Disable Netlet only if you are sure you do not want to use any application with Portal Server.
To Configure the Components
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Core tab.
-
Modify the following attributes:
Attribute Name
Description
Netlet
Select the Enable checkbox to initiate the Netlet service. By default this option is selected.
Proxylet
Select the Enable checkbox to initiate the Proxylet service. By default this option is selected.
-
Restart the Gateway from a terminal window using the following command options:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
Configuring the Basic Options
About the Cookie Management Attribute
Many web sites use cookies to track and manage user sessions. When the Gateway routes requests to web sites that set cookies in the HTTP header, the Gateway either discards or passes-through those cookies in the following manner:
-
Cookies are not rewritten if Enable Cookie Management attribute is not selected in the Gateway service. So, the cookies from the browser might not reach the intranet hosts and vice-versa.
-
Gateway rewrites cookies if the Enable Cookie Management attribute is selected. Gateway ensures that the cookies from the browser reach the intended intranet hosts and vice-versa.
This setting does not apply to the cookies used by Portal Server to track Portal Server user sessions. The setting is controlled by the configuration of the URLs to which User Session Cookie is Forwarded URL option.
This setting applies to all web sites that the user is permitted to access (that is, you cannot choose to discard cookies from some sites and retain cookies from others).
Note –
Do not remove URLs from the Cookie Domain list, even in a Gateway without cookies. See the Access Manager Administration Guide for information on the Cookie Domain list.
About the HTTP Basic Authentication Attribute
HTTP basic authentication can be set in the Gateway service.
Web sites may be protected with HTTP Basic Authentication, requiring visitors to enter a username and password before viewing the site (the HTTP response code is 401 and WWW-authenticate: BASIC). Portal Server can save the username and password so that users need not re-enter their credentials when they revisit BASIC-protected web sites. These credentials are stored in the user profile on the directory server.
This setting does not determine whether or not a user may visit BASIC-protected sites, but only whether the credentials the user enters are saved in the user\qs profile.
This setting applies to all web sites that the user is permitted to access (that is, HTTP basic authentication caching cannot be enabled for some sites and disabled for others).
Note –
Browsing to URLs served by Microsoft\qs Internet Information Server (IIS) protected by Windows NT challenge/response (HTTP response code 401, WWW-Authenticate: NTLM) instead of BASIC authentication is not supported.
You can also enable single sign-on using the Access Control service in the administration console.
About the Portal Servers Attribute
You can configure multiple Portal Servers for the Gateway to service requests. While installing the Gateway, you would have specified the Portal Server that the Gateway needs to work with. This Portal Server is listed in the Portal Servers field by default. You can add more Portal Servers to the list in the format http://portal- server-name:port number. The Gateway tries to contact each of the Portal Servers listed in a round robin manner to service the requests.
About the URLs to Which User Session Cookie is Forwarded Attribute
Portal server utilizes a cookie to track user sessions. This cookie is forwarded to the server when the Gateway makes HTTP requests to the server (for example, when the desktop servlet is called to generate the user\qs desktop page). Applications on the server use the cookie to validate and identify the user.
The Portal Server\qs cookie is not forwarded to HTTP requests made to machines other than the server, unless URLs on those machines are specified in the URLs to which User Session Cookie is Forwarded list. Adding URLs to this list therefore enables servlets and CGIs to receive the Portal Server\qs cookie and use the APIs to identify the user.
URLs are matched using an implicit trailing wildcard. For example, the default entry in the list:
http://server:8080
causes the cookie to be forwarded to all URLs starting with http://server:8080.
Adding:
http://newmachine.eng.siroe.com/subdir
causes the cookie to be forwarded to all URLs starting with that exact string.
For this example, the cookie is not forwarded to any URLs starting with "http://newmachine.eng/subdir", since this string does not start with the exact string in the forward list. To have cookies forwarded to URLs starting with this variation of the machine\qs name, an additional entry has to be added to the forward list.
Similarly, the cookie is not forwarded to URLs starting with "https://newmachine.eng.siroe.com/subdir" unless an appropriate entry is added to the list.
About the Obtain Session from URL Attribute
When the Obtain Session from a URL option is selected, session information is encoded as part of the URL, whether cookies are supported or not. This means that the Gateway uses the session information found in the URL for validation rather than using the session cookie that is sent from the client’s browser.
To Configure the Basic Options
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Core tab.
-
Modify the following attributes:
Attribute Name
Description
Cookie Management
Select the Enable checkbox to enable cookie management.
By default, this option is selected.
HTTP Basic Authentication
Select the Enable HTTP Basic Authentication checkbox to enable HTTP basic authentication.
Portal Servers
Enter the Portal Server in the format http://portal-server-name:port-number in the field and click Add.
Repeat this step to add more Portal Server to the Portal Server list.
URLs to which User Session Cookie is Forwarded
Enter the URL to which User Session Cookie is Forwarded and click Add.
Repeat this step to add more URLs to the URLs to which the User Session is Forwarded list.
Gateway Minimum Authentication Level
Enter the authentication level.
By default, an asterisk is added to allow authentication at all levels.
Obtain Session from URL
Select Yes to retrieve information on a session from a URL.
By default, the No option is selected.
Configuring the Deployment Options
Configuring the Proxy Settings
To Configure the Proxy Settings
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Deployment tab.
-
Modify the following attributes:
Attribute Name
Description
Use Proxy
Select the Use Proxy checkbox to enable the usage of web proxies.
Webproxy URLs
Enter the required URL in the Use Webproxy URLs edit box in the format http://host name.subdomain.com, and then cClick Add.
The URL is added to the Use Webproxy URLs list.
You can specify that the Gateway needs to contact certain URLs only through the webproxies listed in the Proxies for Domains and Subdomains list, even if the Use Proxy option is disabled. You need to specify these URLs in the Use Webproxy URLs field. See Specifying a Proxy to Contact Access Manager for details on how this value affects the usage of proxies.
Proxies for Domains and Subdomains
The entry is added to the Proxies for Domains and Subdomains list box.
The format for entering the proxy information is as follows:
domainname proxy1:port1|subdomain1 proxy2:port2|subdomain2 proxy3:port3|* proxy4:port4
* indicates that the proxy defined after the * needs to be used for all domains and subdomains other than those specifically mentioned.
If you do not specify the port for the proxy, port 8080 is used by default.
See Specifying a Proxy to Contact Access Manager for details on how the proxy information is applied to various hosts.
Proxy Password List
In the Proxy Password List field, enter the information for each proxy server, and then click Add.
The format for entering the proxy information is as follows:
proxyserver|username|password
The proxyserver corresponds to the proxy server defined in the Proxies for Domains and Subdomains list.
You need to specify the user name and password required for the Gateway to authenticate to a specified proxy server, if the proxy server requires authentication to access some or all the sites.
Automatic Proxy Configuration support
Select the Enable Automatic Proxy Configuration Support checkbox to enable PAC support.
If you select the option Enable Automatic Proxy Configuration, the information provided in the Proxies for Domains and Subdomains field is ignored. The Gateway uses the Proxy Automatic Configuration (PAC) file only for intranet configuration. See Using Automatic Proxy Configuration for information on PAC files.
Automatic Proxy Configuration File location
In Location field, enter the name and location of the PAC file.
Configuring the Rewriter Proxy and Netlet Proxy
About NetLet Proxy
The Netlet proxy enhances the security of Netlet traffic between the Gateway and the intranet by extending the secure tunnel from the client, through the Gateway to the Netlet proxy that resides in the intranet.If the Netlet proxy is enabled, the Netlet packets are decrypted by the Netlet proxy and then sent to the destination server. This reduces the number of ports required to be opened in the firewall.
About Rewriter Proxy
The Rewriter proxy enables secure HTTP traffic between the Gateway and intranet. If you do not specify a Rewriter proxy, the Gateway component makes a direct connection to the intranet when a user tries to access a machine on the intranet.The Rewriter proxy does not run automatically after installation. You need to enable the Rewriter proxy as described below.
To Configure the Rewriter Proxy and Netlet Proxy
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
Note –Ensure that the Rewriter proxy and the Gateway use the same gateway profile.
-
Select the Deployment tab.
-
Modify the following attributes:
-
Run portal-server-install-root/SUNWportal/bin/certadmin on the server to create a certificate for the Rewriter proxy.
You need to do this step only if you have not chosen to create a certificate while installing the Rewriter proxy.
-
Log in as root to the machine where the Rewriter proxy is installed and start the Rewriter proxy:
rewriter-proxy-install-root/SUNWportal/bin/rwproxyd -n gateway-profile-name start
-
Log in as root to the machine where the Gateway is installed and restart the Gateway:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
Configuring the Security Options
Configuring the PDC and Non Authenticated URLs
To Configure the PDC and Non Authenticated URLs
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Security tab.
-
Modify the following attributes:
Configuring the TLS and SSL Options
To Configure the TLS and SSL Options
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Security tab.
-
Modify the following attributes:
Configuring the Performance Options
Configuring the Timeouts and Retries
To Configure the Timeouts and Retries
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Performance tab.
-
Modify the following attributes:
Attribute Name
Description
Server Retry Interval (seconds)
Specify the time interval in seconds between requests to try to start the Portal Server, Rewriter proxy, or Netlet proxy if it becomes unavailable (such as a crash or it was brought down).
Gateway Timeout (seconds)
Specify the time interval in seconds after which the Gateway times out its connection with the browser.
In the Gateway Timeout field, specify the interval required in seconds.
Cached Socket Timeout (seconds)
Specify the time interval in seconds after which the Gateway times out its connection with the Portal Server.
Configuring the HTTP Options
To Configure the HTTP Options
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Performance tab.
-
Modify the following attributes:
Monitoring the Secure Remote Access Performance
Monitoring allows administrators to assess the performance of different components of the Secure Remote Access.
To Monitor Secure Remote Access Performance
-
Log in to the Portal Server management console.
-
Select the Secure Remote Access tab, and click Monitoring in the submenu.
-
In the Monitoring page, select a proxy instance from the drop-down menu.
-
Select an attribute in the MBeans table to view performance values.
Configuring the Rewriter Options
Configuring the Basic Options
To Configure the Basic Options
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Rewriter tab.
-
Modify the following attributes:
Attribute Name
Description
Rewriting of All URIs
Select the Enable Rewriting of All URIs checkbox to enable the Gateway to rewrite all URLs.
If you enable the Enable Rewriting of All URIs option in the Gateway service, Rewriter rewrites any URL without checking against the entries in the Proxies for Domains and Subdomains list. Entries in the Proxies for Domains and Subdomains list are ignored.
URIs Not to Rewrite
Add the URI in the edit box.
Note –Adding #* to this list allows URIs to be rewritten, even when the href rule is part of the ruleset.
Configuring the Map URIs to RuleSets
Rulesets are created in the Rewriter service under Portal Server Configuration in the Portal Server management console. See the Portal Server Administration Guide for details.
After the ruleset is created, you associate a domain with the ruleset using the Map URIs to RuleSets field. The following two entries are added by default to the Map URIs to RuleSets field:
-
*://*.Sun.COM/portal/*|default_gateway_ruleset
where sun.com is the install domain of the portal and /portal is the portal install context
-
*|generic_ruleset
This means that for all pages from the default domain, the default Gateway ruleset is applied. For all other pages, the generic ruleset is applied. The default Gateway ruleset and the generic ruleset are pre-packaged rulesets.
Note –
For all the content appearing on the desktop, the ruleset for the default domain is used, irrespective of where the content is fetched from.
For example, assume that the desktop is configured to scrape the content from the URL yahoo.com. The Portal Server is in sesta.com. The ruleset for sesta.com is applied to the fetched content.
Note –
The domain for which you specify a ruleset must be listed in the Proxies for Domains and Subdomains list.
To Configure the Map URIs to RuleSets
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab, and click the profile name to modify its attributes.
-
Select the Rewriter tab.
-
Modify the following attributes:
Configuring the Map Parser to MIME Types
Rewriter has four different parsers to parse the web pages based on the content type - HTML, JAVASCRIPT, CSS and XML. Common MIME types are associated with these parsers by default. You can associate new MIME types with these parsers in the Map Parser to MIME Types field of the Gateway service. This extends Rewriter functionality to other MIME types.
Separate multiple entries with a semicolon or a comma (";" or ",".)
For example:
HTML=text/html;text/htm;text/x-component;text/wml; text/vnl/wap.wml
means any content with these MIMEs are sent to the HTML Rewriter and HTML Rules would be applied to rewrite the URLs.
Tip –
Removing unnecessary parsers from the MIME mappings list can increase the speed of operation. For example, if you are sure that the content from a certain intranet does not have any JavaScript, you can remove the JAVASCRIPT entry from the MIME mappings list.
To Configure the Map Parser to MIME Types
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and click the profile name to modify its attributes.
-
Select the Rewriter tab.
-
Modify the following attributes:
Attribute Name
Description
Parsers
-
In the Map Parser to MIME Types field, add the required MIME type in the Edit box. Use a semicolon or comma to separate multiple entries.
Specify the entry in the format HTML=text/html;text/htm
-
Click Add to add the required entry to the list.
-
Configuring Personal Digital Certificate Authentication
PDCs are issued by a Certification Authority (CA) and signed with the CA's private key. The CA validates the identity of a requesting body before issuing a certificate. Thus the presence of a PDC is a powerful authentication mechanism.
PDCs contain the owner's public key, the owner's name, an expiration date, the name of the Certification Authority that issued the Digital Certificate, a serial number, and maybe some other information.
Users can use PDCs and encoded devices such as Smart Cards and Java Cards for authentication in the Portal Server. The encoded devices carry an electronic equivalent of a PDC stored on the card. If a user logs in using one of these mechanisms, no Log in screen displays and no authentication screen is displayed.
-
From a browser, the user types a connection request, say https://my.sesta.com.
The response to this request depends on whether the Gateway to my.sesta.com has been configured to accept certificates.
Note –When a Gateway is configured to accept certificates, it accepts only logins with certificates, not any other kind of login.
The Gateway checks that the certificate has been issued by a known Certificate Authority, has not expired, and has not been tampered with. If the certificate is valid, the Gateway lets the user proceed to the next step in the authentication process.
-
The Gateway passes the certificate to the PDC authentication module in the server.
The PDC authentication process involves several steps:
To Configure PDCs and Encoded Devices
-
Add the following line in the /etc/opt/SUNWam/config/AMConfig.properties file on the Portal Server machine: com.iplanet.authentication.modules.cert.gwAuthEnable=yes.
-
Import the Required Certificates into the certificate database of the Gateway that you want PDC-enabled. To configure the certificates, see To import the Root CA certificate on the gateway machine
-
Log into the Access Manager administration console as administrator, do the following:
-
From the Access Manager administration console, do the following:
-
From the Access Manager administration console, do the following:
-
Choose the required organization and then select Services from the View drop-down menu.
The list of services is displayed.
-
Click the arrow next to the Authentication Configuration core service and then click New.
The New Service Instance page is displayed.
-
Enter the service instance name as gatewaypdc.
-
Click Submit.
The gatewaypdc Service Instance List is displayed.
-
Click gatewaypdc to edit the service.
The gatewaypdc show properties page is displayed.
-
Click Edit link next to Authentication Configuration and then click Add.
The Add Module page is displayed.
-
Choose Cert from the Module Name field and REQUIRED for Enforcement criteria, and then click OK.
-
Click OK to complete.
-
-
From the Access Manager administration console, do the following:
-
Log into the Portal Server administration console as administrator and do the following:
-
Restart the gateway profile from a terminal window:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
-
Install the client certificate issued from CA into the browser one has to access PDC enabled gateway.
-
Install the client certificate into the JVM keystore. JVM control panel can be accessed as below from the windows machine Start > Setting > Control Panel > Java.
Add the following to the Applet RunTime parameters:
-
Djavax.net.ssl.keyStore=Path to Keystore
-
Djavax.net.ssl.keyStorePassword=password
-
Djavax.net.ssl.keyStoreType=type
-
-
Access your gateway profile and organization:
https://gateway:instance-port/YourOrganization
You should be logged in without any prompt for Username and Password with the name of the certificate.
To import the Root CA certificate on the gateway machine
-
Import the Root CA certificate on the gateway machine.
-
<Gateway-Install-Dir>/SUNWportal/bin/certadmin -n <gw-profile-name>
Certadmin menu is listed.
-
Select option 3. Enter the path for the certificates.
For more information, see the Chapter 10, Working with Certificates.
-
-
Generate a Certificate Signing Request for submitting to the CA.
-
Submit the Certificate Signing Request to a CA and get it approved. Save the certificate response after CA signing.
-
Import the Server Certificate after getting approved by CA.
-
Import the Root CA certificate on the Portal Server machine.
Configuring Gateway Attributes Using the Command Line Options
This section provides the command line options to configure Gateway attributes from the terminal window for the following tasks:
To Manage Storage of External Server Cookies
When the Store External Server Cookies option is enabled, Gateway stores and manages cookies for any third party application or server that is accessed through the Gateway. Although the application or server cannot service cookieless devices or depends on cookies for state management, Gateway transparently masks the application or server from knowing that the Gateway is servicing a cookieless device.
For information on cookieless devices and client detection, see the Access Manager Customization and API Guide.
-
To enable:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a CookieManagement true
-
To disable:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a CookieManagement false
-
To get attribute value:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a CookieManagement
Type the following command and press Enter to manage storage of external server cookies.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Enable Marking Cookies as Secure
When a cookie is marked as secure, the browser treats the cookie with additional security. The implementation of security depends on the browser. The Enable Cookie Management attribute must be enabled for this to work.
-
To enable:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a MarkCookiesSecure true
-
To disable:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a MarkCookiesSecure false
-
To get the attribute value:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a MarkCookiesSecure
Type the following command and press Enter to mark cookies as secure.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Create List of URLs for Proxies Not to be Used
The Gateway tries to connect directly to the URLs listed in the Do Not Use Webproxy URLs list. A webproxy is not used to connect to these URLs.
-
To specify URLs not to be used:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a DontUseWebProxyURL -A "LIST_OF_URLS"
-
To add to the existing list of URLs:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a DontUseWebProxyURL -A "LIST_OF_URLS"
-
To remove from the existing list of URLs:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a DontUseWebProxyURL -E "LIST_OF_URLS"
-
To get the existing list of URLs:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a DontUseWebProxyURL
Type the following command and press Enter to manage URLs for proxies not to be used.
Note –
Separate each URL with a blank space where there are more than one URL.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Manage RuleSet to URI Mapping
Secure Remote Access supports Microsoft Exchange 2000 SP3 installation and MS Exchange 2003 of Outlook Web Access (OWA).
-
To add a RuleSet
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile default -a DomainsAndRulesets -A "EXCHANGE2000_SERVER_NAME exchange_2000sp3_owa_ruleset"
-
To remove a RuleSet:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile default -a DomainsAndRulesets -E "EXCHANGE2000_SERVER_NAME exchange_2000sp3_owa_ruleset"
-
To set a list of URIs to RuleSet mappings:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a DomainsAndRulesets "URI|RULE_SET_NAME URI|RULE_SET_NAME"
To add a URI to the existing list:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile default -a DomainsAndRulesets -A "URI|RULE_SET_NAME URI|RULE_SET_NAME"
To remove a URI from the existing list:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile default -a DomainsAndRulesets -E "URI|RULE_SET_NAME URI|RULE_SET_NAME"
To get the existing list:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a DomainsAndRulesets
Type the following command and press Enter to manage RuleSet for Outlook Web Access.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Specify the Default Domain
The default domains are useful when URLs contain only the host names without the domain and subdomain. In this case, the Gateway assumes that the host names are in the default domain list, and proceeds accordingly.
For example, if the host name in the URL is host1, and the default domain and subdomain are specified as red.sesta.com, the host name is resolved as host1.red.sesta.com.
-
To set default domain:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a DefaultDomainsAndSubdomains "DOMAIN_NAME"
-
To get the default domain:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a DefaultDomainsAndSubdomains
Type the following command and press Enter to specify the default domains.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Manage MIME Guessing
Rewriter depends on the MIME type of the page to choose the parser. Some web servers such as WebLogic and Oracle do not send MIME types. To work around this, you can enable the MIME guessing feature by adding data to the Map Parser to URIs list box.
-
To enable MIME guessing:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a EnableMIMEGuessing true
-
To disable MIME guessing:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a EnableMIMEGuessing false
-
To get value:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a EnableMIMEGuessing
Type the following command and press Enter to manage MIME guessing.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Create a List of URI Mappings to Parse
If the MIME Guessing checkbox is enabled and the server has not sent a MIME type, use this list box to map the parser to the URI.
Multiple URIs are separated by a semicolon.
For example HTML=*.html; *.htm;*Servlet. This means that the HTML Rewriter is used to rewrite the content for any page with a html, htm, or Servlet extension.
-
To set a list of URI mappings to parse:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a MIMEMap
-
To add to the existing list:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a MIMEMap -A LIST
-
To remove from the existing list:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a MIMEMap -E LIST
-
To get the existing list:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME-a MIMEMap
Type the following command and press Enter to create a list of URI mappings to parse.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Manage Masking
Masking allows Rewriter to rewrite a URI so that the intranet URL of a page is not seen.
-
To enable masking:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a EnableObfuscation true
-
To disable masking:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a EnableObfuscation false
-
To get value:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a EnableObfuscation
Type the following command and press Enter to manage masking.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Specify the masking Seed String
A seed string is used for masking a URI. A masking algorithm generates the string.
Note –
Book marking of an masked URI may not work if this seed string has been changed or if the Gateway is restarted.
-
To set the masking seed string:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a ObfuscationSecretKey SECRET_KEY
-
To get the value:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a ObfuscationSecretKey
Type the following command and press Enter to specify the masking seed string.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Create a List of URIs Not to Mask
Some applications (such as an applet) require an Internet URI and cannot be masked. To specify those applications, add the URI to the list box.
For example if you added */Applet/Param* to the list box, the URL would not be masked if the content URI http://abc.com/Applet/Param1.html is matched in the RuleSet rule.
Note –
Separate each URI with a blank space where there are more than one URI.
-
To set a list of URIs not to mask:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a NotToObscureURIList LIST_OF_URI
-
To add to the existing list:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a NotToObscureURIList -A LIST_OF_URI
-
To remove from the existing list:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a NotToObscureURIList -E LIST_OF_URI
-
To get the existing values:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a NotToObscureURIList
Type the following command and press Enter to create a list of URIs not to mask.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
To Make a Gateway Protocol the Same as the Original
URI Protocol
When a Gateway runs in both HTTP and HTTPS mode, you can enable Rewriter to use a consistent protocol to access the referred resources in the HTML content.
For example, if the original URL is http://intranet.com/Public.html then the http Gateway is added. If the original URL is https://intranet.com/Public.html then the https Gateway is added.
Note –
This applies only to static URIs and not to dynamic URIs generated in Javascript.
-
To enable:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a UseConsistentProtocolForGateway true
-
To disable:
PS_INSTALL_DIR/bin/psadmin set-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a UseConsistentProtocolForGateway false
-
To get the value:
PS_INSTALL_DIR/bin/psadmin get-attribute -u amadmin -f PASSWORD_FILE -m gateway --gateway-profile PROFILE_NAME -a UseConsistentProtocolForGateway
Type the following command and press Enter to make a Gateway protocol the same as the original URI protocol.
See also
psadmin set-attribute in Sun Java System Portal Server 7.2 Command-Line Reference and psadmin get-attribute in Sun Java System Portal Server 7.2 Command-Line Reference
Chapter 9 Configuring Rewriter in the Gateway Service
highlights content here.
This chapter has the following sections:
For more information on rewriter rules, see Defining Language Based Rules
For more information on Rewriter problems, see Troubleshooting Using Debug Logs.
For Rewriter examples, see Working Samples.
Creating a List of URIs to RuleSet Mappings
After the ruleset is created, associate a domain with the ruleset using the Map URIs to RuleSets field. The following two entries are added by default to the Map URIs to RuleSets field:
-
*://*.Sun.COM/portal/*|default_gateway_ruleset
where sun.com is the install domain of the portal and /portal is the portal install context
This means that for all pages from portal directory with the domain sun.com, the default_gateway_ruleset is applied. For all other pages, the generic ruleset is applied. The default_gateway_ruleset and the generic_ruleset are pre-packaged rulesets.
Note –
For all the content appearing on the standard Portal Desktop, the ruleset for the default_gateway_ruleset is used, irrespective of where the content is fetched from.
For example, assume that the standard Portal Desktop is configured to scrape the content from the URL yahoo.com. The Portal Server is in sesta.com. The ruleset for sesta.com is applied to the fetched content.
Note –
The domain for which you specify a ruleset must be listed in the Proxies for Domains and Subdomains list.
Using Wildcards Within the Syntax
You can map a fully qualified URI or a partial URI by using an asterisk in the ruleset.
For example, you could apply the java_index_page_ruleset to an index.html page as follows:
www.sun.com/java/index.html/java_index_page_ruleset
or you could apply all pages in the java directory to the java_directory_ruleset, as follows:
www.sun.com/java/* /java_directory_ruleset
Configuring Rewriter in the Gateway Service
Using the Gateway service, under the Rewriter tab, you can perform the following tasks within two categories, Basic and Advanced:
Basic Tasks
To Enable the Gateway to Rewrite All URLs
If you enable the Enable Rewriting of All URIs option in the Gateway service, Rewriter rewrites any URL without checking against the entries in the Proxies for Domains and Subdomains list. Entries in the Proxies for Domains and Subdomains list are ignored.
-
Log into the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab, and select the gateway profile for which you want to modify the attributes.
-
Select the Rewriter tab.
-
Under Basic Options, select the Enable Rewriting of All URIs checkbox to enable the Gateway to rewrite all URLs.
-
Click Save to complete.
-
Restart the Gateway from a terminal window:
./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>
To Specify the URIs Not to Rewrite
-
Log into the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab, and select the gateway profile for which you want to set the attribute.
-
Select the Rewriter tab.
-
Under Basic Option, enter the URI in the Add text field and then click Add.
The URI values is displayed in the URIs Not To Rewrite box.
Note –Adding #* to this list allows URIs to be rewritten, even when the href rule is part of the ruleset.
-
Click Save to complete.
-
Restart the Gateway from a terminal window:
./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>
To Map a URI to a RuleSet
-
Log into the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab, and select the gateway profile for which you want to set the attribute.
-
Select the Rewriter tab.
-
Under Rewriter Options, click Map URI to Rulesets, and click Add Row.
-
Enter the required domain or host name in the URI field and the enter appropriate ruleset for the domain in the Rule Set field.
The entry is added to the Map URIs to RuleSets list. The format for specifying the domain or host name and the ruleset is as follows:
domain name|ruleset name
For example:
eng.sesta.com|default
-
Click Save to Complete.
-
Restart the Gateway from a terminal window:
./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>
To Specify MIME Mappings
Rewriter has four different parsers to parse the web pages based on the content type: HTML, JAVASCRIPT, CSS and XML. Common MIME types are associated with these parsers by default. You can associate new MIME types with these parsers in the Map Parser to MIME Types field of the Gateway service. This extends the Rewriter functionality to other MIME types.
Separate multiple entries with a semicolon or a comma (";" or ",".) For example:
HTML=text/html;text/htm;text/x-component;text/wml; text/vnl/wap.wml
means any content with these MIMEs are sent to the HTML Rewriter and HTML rules would be applied to rewrite the URLs.
Tip –
Removing unnecessary parsers from the MIME mappings list can increase the speed of operation. For example, if you are sure that the content from a particular intranet will not have any JavaScript, you can remove the JAVASCRIPT entry from the MIME mappings list.
-
Log into the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab, and select the gateway profile for which you want to set the attribute.
-
Select the Rewriter tab.
-
Under Rewriter Option, click Map Parser to Map MIME Types .
Specify the entry in the format HTML=text/html;text/htm
-
Click Add Row to add the entry to the list. Enter the parser value and corresponding MIME value to map to in the MIME Type filed.
-
Click Save to complete.
-
Restart the Gateway from a terminal window:
./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>
To Specify the Default Domains
The default domain and subdomain are useful when URLs contain only the host names without the domain and subdomain. In this case, the Gateway assumes that the host names are in the default domain and subdomain, and proceeds accordingly.
For example, if the host name in the URL is host1, and the default domain and subdomain are specified as red.sesta.com, the host name is resolved as host1.red.sesta.com.
-
Log into the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab, and select the gateway profile for which you want to set the attribute.
-
Select Deployment Tab.
-
In the Proxies for Domains and Subdomains field, type the required domain name with out proxy.
-
Click Save to complete.
-
Restart the Gateway from a terminal window:
./psadmin start-sra-instance –u amadmin – f <password file> –N <profile name>– t <gateway>
Chapter 10 Working with Certificates
This chapter describes certificate management and explains how to install self-signed certificates and certificates from a Certificate Authority.
This chapter explains the following topics:
Introduction to SSL Certificates
The Sun Java System Portal Server Secure Remote Access software provides certificate-based authentication for remote users. SRA uses Secure Sockets Layer (SSL) to enable secure communication. The SSL protocol enables secure communication between two machines.
A SSL certificate provides encryption and decryption capabilities using a public and private key pair.
The two types of certificates are:
-
Self-signed certificates (also called root CA certificate)
-
Certificates issued by Certificate Authority (CA)
By default, a self-signed certificate is generated and installed when you install the Gateway.
You can generate, obtain, or replace a certificate anytime after installation.
SRA also supports client authentication with Personal Digital Certificates (PDCs). PDCs are a mechanism to authenticate a user through SSL client authentication. With SSL client authentication, the SSL handshake ends at the Gateway. The Gateway extracts the user’s PDC and passes it to the authenticated server. This server uses the PDC to authenticate the user. To configure PDCs along with Authentication Chaining, see Using Authentication Chaining.
SRA provides a tool named certadmin that you can use to manage the SSL certificates. See The certadmin Script.
Note –
Certificate pop up windows are common in SSL applications. Advise users to accept the warning and proceed.
Certificate Files
Certificate related files are located in /etc/opt/SUNWportal/cert/gateway-profile-name. This directory contains 5 files by default.
Certificate Files lists these files and their descriptions.
Table 10–1 Certificate Files|
File Name |
Type |
Description |
|---|---|---|
|
cert8.db, key3.db, secmod.db |
Binary |
Contains the data for certificates, keys, and cryptographic modules. Can be manipulated using the certadmin script. If necessary, these files can be shared between the Portal Server host and gateway components or the Gateway. |
|
.jsspass |
hidden text file |
Contains the encrypted password for the SRA key database. |
|
.nickname |
hidden text file |
Stores the names of the token and certificate that the Gateway needs to use in the format token-name:certificate-name. If you are using the default token (the token on the default internal software encryption module), omit the token name. In most cases, the .nickname file stores only the certificate name. As an administrator, you can modify the certificate name in this file. The certificate that you specify is now used by the Gateway. |
Certificate Trust Attributes
The trust attributes of a certificate indicate the following information:
-
Whether the certificate (in the case of client or server certificate) was issued by a Trusted CA.
-
Whether the certificate (in the case of a root certificate) can be trusted as the issuer of a server or client certificate.
The three available trust categories for each certificate are expressed in this order: “SSL, email, object signing”. Only the first category is useful for the Gateway. In each category position, zero or more trust attribute codes are used.
The attribute codes for the categories are separated by commas, and the entire set of attributes is enclosed by quotation marks. For example, the self-signed certificate generated and installed during the Gateway installation is marked "u,u,u" which means the certificate is a server certificate (user certificate) and not a root CA certificate.
Certificate Trust Attributes lists the possible attribute values and the meaning of each value.
Table 10–2 Certificate Trust Attributes|
Attribute |
Description |
|---|---|
|
p |
Valid peer |
|
P |
Trusted peer (implies p) |
|
c |
Valid CA |
|
T |
Trusted CA to issue client certificates (implies c) |
|
C |
Trusted CA to issue server certificates (SSL only) (implies c) |
|
u |
Certificate can be used for authentication or signing |
|
w |
Send warning (use with other attributes to include a warning when the certificate is used in that context) |
CA Trust Attributes
Most well-known public CAs are included in the certificate database. See Modifying the Trust Attributes of a Certificate for information on modifying the trust attributes of a public CA.
CA Trust Attributes lists the most common Certificate Authorities with the trust attributes.
Table 10–3 Public Certificate Authorities|
Certificate Authority Name |
Trust Attribute |
|
Verisign/RSA Secure Server CA |
CPp,CPp,CPp |
|
VeriSign Class 4 Primary CA |
CPp,CPp,CPp |
|
GTE CyberTrust Root CA |
CPp,CPp,CPp |
|
GTE CyberTrust Global Root |
CPp,CPp,CPp |
|
GTE CyberTrust Root 5 |
CPp,CPp,CPp |
|
GTE CyberTrust Japan Root CA |
CPp,CPp,CPp |
|
GTE CyberTrust Japan Secure Server CA |
CPp,CPp,CPp |
|
Thawte Personal Basic CA |
CPp,CPp,CPp |
|
Thawte Personal Premium CA |
CPp,CPp,CPp |
|
Thawte Personal Freemail CA |
CPp,CPp,CPp |
|
Thawte Server CA |
CPp,CPp,CPp |
|
Thawte Premium Server CA |
CPp,CPp,CPp |
|
American Express CA |
CPp,CPp,CPp |
|
American Express Global CA |
CPp,CPp,CPp |
|
Equifax Premium CA |
CPp,CPp,CPp |
|
Equifax Secure CA |
CPp,CPp,CPp |
|
BelSign Object Publishing CA |
CPp,CPp,CPp |
|
BelSign Secure Server CA |
CPp,CPp,CPp |
|
TC TrustCenter, Germany, Class 0 CA |
CPp,CPp,CPp |
|
TC TrustCenter, Germany, Class 1 CA |
CPp,CPp,CPp |
|
TC TrustCenter, Germany, Class 2 CA |
CPp,CPp,CPp |
|
TC TrustCenter, Germany, Class 3 CA |
CPp,CPp,CPp |
|
TC TrustCenter, Germany, Class 4 CA |
CPp,CPp,CPp |
|
ABAecom (sub., Am. Bankers Assn.) Root CA |
CPp,CPp,CPp |
|
Digital Signature Trust Co. Global CA 1 |
CPp,CPp,CPp |
|
Digital Signature Trust Co. Global CA 3 |
CPp,CPp,CPp |
|
Digital Signature Trust Co. Global CA 2 |
CPp,CPp,CPp |
|
Digital Signature Trust Co. Global CA 4 |
CPp,CPp,CPp |
|
Deutsche Telekom AG Root CA |
CPp,CPp,CPp |
|
Verisign Class 1 Public Primary Certification Authority |
CPp,CPp,CPp |
|
Verisign Class 2 Public Primary Certification Authority |
CPp,CPp,CPp |
|
Verisign Class 3 Public Primary Certification Authority |
CPp,CPp,CPp |
|
Verisign Class 1 Public Primary Certification Authority - G2 |
CPp,CPp,CPp |
|
Verisign Class 2 Public Primary Certification Authority - G2 |
CPp,CPp,CPp |
|
Verisign Class 3 Public Primary Certification Authority - G2 |
CPp,CPp,CPp |
|
Verisign Class 4 Public Primary Certification Authority - G2 |
CPp,CPp,CPp |
|
GlobalSign Root CA |
CPp,CPp,CPp |
|
GlobalSign Partners CA |
CPp,CPp,CPp |
|
GlobalSign Primary Class 1 CA |
CPp,CPp,CPp |
|
GlobalSign Primary Class 2 CA |
CPp,CPp,CPp |
|
GlobalSign Primary Class 3 CA |
CPp,CPp,CPp |
|
ValiCert Class 1 VA |
CPp,CPp,CPp |
|
ValiCert Class 2 VA |
CPp,CPp,CPp |
|
ValiCert Class 3 VA |
CPp,CPp,CPp |
|
Thawte Universal CA Root |
CPp,CPp,CPp |
|
Verisign Class 1 Public Primary Certification Authority - G3 |
CPp,CPp,CPp |
|
Verisign Class 2 Public Primary Certification Authority - G3 |
CPp,CPp,CPp |
|
Verisign Class 3 Public Primary Certification Authority - G3 |
CPp,CPp,CPp |
|
Verisign Class 4 Public Primary Certification Authority - G3 |
CPp,CPp,CPp |
|
Entrust.net Secure Server CA |
CPp,CPp,CPp |
|
Entrust.net Secure Personal CA |
CPp,CPp,CPp |
|
Entrust.net Premium 2048 Secure Server CA |
CPp,CPp,CPp |
|
ValiCert OCSP Responder |
CPp,CPp,CPp |
|
Baltimore CyberTrust Code Signing Root |
CPp,CPp,CPp |
|
Baltimore CyberTrust Root |
CPp,CPp,CPp |
|
Baltimore CyberTrust Mobile Commerce Root |
CPp,CPp,CPp |
|
Equifax Secure Global eBusiness CA |
CPp,CPp,CPp |
|
Equifax Secure eBusiness CA 1 |
CPp,CPp,CPp |
|
Equifax Secure eBusiness CA 2 |
CPp,CPp,CPp |
|
Visa International Global Root 1 |
CPp,CPp,CPp |
|
Visa International Global Root 2 |
CPp,CPp,CPp |
|
Visa International Global Root 3 |
CPp,CPp,CPp |
|
Visa International Global Root 4 |
CPp,CPp,CPp |
|
Visa International Global Root 5 |
CPp,CPp,CPp |
|
beTRUSTed Root CA |
CPp,CPp,CPp |
|
Xcert Root CA |
CPp,CPp,CPp |
|
Xcert Root CA 1024 |
CPp,CPp,CPp |
|
Xcert Root CA v1 |
CPp,CPp,CPp |
|
Xcert Root CA v1 1024 |
CPp,CPp,CPp |
|
Xcert EZ |
CPp,CPp,CPp |
|
CertEngine CA |
CPp,CPp,CPp |
|
BankEngine CA |
CPp,CPp,CPp |
|
FortEngine CA |
CPp,CPp,CPp |
|
MailEngine CA |
CPp,CPp,CPp |
|
TraderEngine CA |
CPp,CPp,CPp |
|
USPS Root |
CPp,CPp,CPp |
|
USPS Production 1 |
CPp,CPp,CPp |
|
AddTrust Non-Validated Services Root |
CPp,CPp,CPp |
|
AddTrust External Root |
CPp,CPp,CPp |
|
AddTrust Public Services Root |
CPp,CPp,CPp |
|
AddTrust Qualified Certificates Root |
CPp,CPp,CPp |
|
Verisign Class 1 Public Primary OCSP Responder |
CPp,CPp,CPp |
|
Verisign Class 2 Public Primary OCSP Responder |
CPp,CPp,CPp |
|
Verisign Class 3 Public Primary OCSP Responder |
CPp,CPp,CPp |
|
Verisign Secure Server OCSP Responder |
CPp,CPp,CPp |
|
Verisign Time Stamping Authority CA |
CPp,CPp,CPp |
|
Thawte Time Stamping CA |
CPp,CPp,CPp |
|
E-Certify CA |
CPp,CPp,CPp |
|
E-Certify RA |
CPp,CPp,CPp |
|
Entrust.net Global Secure Server CA |
CPp,CPp,CPp |
|
Entrust.net Global Secure Personal CA |
CPp,CPp,CPp |
The certadmin Script
You can use the certadmin script to do the following certificate administration tasks:
Generating Self-Signed Certificates
You need to generate certificates for SSL communication between each server and Gateway.
To Generate a Self-Signed Certificate After Installation
-
As root, run the certadmin script on the Gateway machine for which you want to generate a certificate:
portal-server-install-root/SUNWportal/bin/certadmin -n gateway-profile-name
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10) Quit choice: [10] 1
-
Choose option 1 on the certificate administration menu.
The certificate administration script asks you if you want to keep the existing database files.
-
Enter organization-specific information, token name, and the certificate name.
Note –For a wild card certificate, specify a * in the fully-qualified DNS name of the host. For example, if the fully-qualified DNS name of the host is abc.sesta.com, specify it as *.sesta.com. The certificate that is generated is now valid for all host names in the sesta.com domain.
What is the fully-qualified DNS name of this host? [host_name.domain_name] What is the name of your organization (ex: Company)? [] What is the name of your organizational unit (ex: division)? [] What is the name of your City or Locality? [] What is the name (no abbreviation please) of your State or Province? [] What is the two-letter country code for this unit? [] Token name is needed only if you are not using the default internal (software) cryptographic module, for example, if you want to use a crypto card (Token names could be listed using: modutil -dbdir /etc/opt/SUNWportal/cert/gateway-profile-name -list); Otherwise, just hit Return below. Please enter the token name. [] Enter the name you like for this certificate? Enter the validity period for the certificate (months) [6] A self-signed certificate is generated and the prompt returns.
The token name (default being empty) and certificate name are stored in the .nickname file under /etc/opt/SUNWportal/cert/gateway-profile-name.
-
Restart the Gateway for the certificate to take effect:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
Generating a Certificate Signing Request (CSR)
Before you can order a certificate from a CA, you need to generate a certificate signing request which contains the information that is required by the CA.
To Generate a CSR
-
As root, run the certadmin script:
portal-server-install-root/SUNWportal/bin/certadmin -n gateway-profile-name
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10) Quit choice: [10] 2
-
Choose option 2 on the certificate administration menu.
The script prompts you for organization-specific information, token name, and web master’s email and phone number.
Ensure that you specify the fully-qualified DNS name of the host.
What is the fully-qualified DNS name of this host? [snape.sesta.com] What is the name of your organization (ex: Company)? [] What is the name of your organizational unit (ex: division)? [] What is the name of your City or Locality? [] What is the name (no abbreviation please) of your State or Province? [] What is the two-letter country code for this unit? [] Token name is needed only if you are not using the default internal (software) cryptographic module, for example, if you want to use a crypto card (Token names could be listed using: modutil -dbdir /etc/opt/SUNWportal/cert -list); Otherwise, just hit Return below. Please enter the token name [] Now input some contact information for the webmaster of the machine that the certificate is to be generated for. What is the email address of the admin/webmaster for this server [] ? What is the phone number of the admin/webmaster for this server [] ?
-
Type all the required information.
Note –Do not leave the web master’s email and phone number blank. The information is necessary for obtaining a valid CSR.
A CSR is generated and stored in the file portal-server-install-root/SUNWportal/bin/csr.hostname.datetimestamp. The CSR is also printed on the screen. You can directly copy and paste the CSR when you order a certificate from a CA.
Adding a Root CA Certificate
If a client site presents a certificate signed by a CA that is unknown to the Gateway certificate database, the SSL handshake fails.
To prevent this, you need to add a root CA certificate to the certificate database. This ensures that the CA becomes known to the Gateway.
Browse to the CA’s website and obtain the root certificate for that CA. When you use the certadmin script, specify the file name and path of the root CA certificate.
To Add a Root CA Certificate
-
As root, run the certadmin script.
portal-server-install-root/SUNWportal/bin/certadmin -n gateway-profile-name
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10) Quit choice: [10] 3
-
Choose option 3 on the certificate administration menu.
-
Enter the name of the file that contains the root certificate and enter the name of the certificate.
The root CA certificate is added to the certificate database.
Installing SSL Certificates From the Certificate Authority
During the installation of the Gateway, a self-signed certificate is created and installed by default. At any point after installation, you can install SSL certificates signed by vendors who provide official certificate authority (CA) services, or by your corporate CA.
The three steps involved in this task are:
Ordering a Certificate from a CA
After generating a certificate signing request (CSR), you need to order the certificate from the CA using a CSR.
To Order a Certificate From a CA
-
Go to the Certificate Authority’s web site and order your certificate.
-
Provide the CSR as requested by the CA. Provide other information if requested by the CA.
You will receive your certificate from the CA. Save it in a file. Include the "BEGIN CERTIFICATE" and "END CERTIFICATE" lines with the certificate in the file.
The following example omits the actual certificate data.
-----BEGIN CERTIFICATE----- The certificate contents... ----END CERTIFICATE-----
Installing a Certificate from a CA
Using the certadmin script, install the certificate obtained from the CA in your local database files in /etc/opt/SUNWportal/cert/gateway-profile-name.
To Install a Certificate From a CA
-
As root, run the certadmin script.
portal-server-install-root/SUNWportal/bin/certadmin -n gateway-profile-name
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10)Quit choice: [10] 4
-
Choose option 4 on the certificate administration menu.
The script asks you to enter the certificate file name, certificate name, and the token name.
What is the name (including path) of file that contains the certificate? Please enter the token name you used when creating CSR for this certificate. []
-
Supply all the required information.
The certificate is installed in /etc/opt/SUNWportal/cert/gateway-profile-name, and the screen prompt returns.
-
Restart the Gateway for the certificate to take effect:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
Deleting a Certificate
You can delete a certificate by using the certificate administration script.
To Delete a Certificate
-
As root, run the certadmin script.
portal-server-install-root/SUNWportal/bin/certadmin -n
where gateway-profile-name is the name of the Gateway instance.
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10)Quit choice: [10] 5
-
Choose option 5 on the certificate administration menu.
-
Enter the name of the certificate to be deleted.
Modifying the Trust Attributes of a Certificate
One case in which the trust attributes of a certificate needs to be modified is if client authentication is used with the Gateway. An example of client authentication is PDC (Personal Digital Certificate). The CA that issues the PDCs must be trusted by the Gateway, and the CA certificate must be marked "T" for SSL.
If the Gateway is set up to communicate with an HTTPS site, the CA of the HTTPS site server certificate must be trusted by the Gateway, and the CA certificate must be marked "C" for SSL.
To Modify the Trust Attributes for a Certificate
-
As root, run the certadmin script.
gateway-install-root/SUNWportal/bin/certadmin -n gateway-profile-name
where gateway-profile-name is the name of the Gateway instance.
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10)Quit choice: [10] 6
-
Choose option 6 on the certificate administration menu.
-
Enter the name of the certificate. For example, Thawte Personal Freemail CA.
Please enter the name of the certificate? Thawte Personal Freemail CA
-
Enter the trust attribute for the certificate.
Please enter the trust attribute you want the certificate to have [CT,CT,CT]
The certificate trust attribute will be changed.
Listing Root CA Certificates
You can view all root CA certificates by using the certificate administration script.
To View the List of Root CAs
-
As root, run the certadmin script.
portal-server-install-root/SUNWportal/bin/certadmin -n gateway-profile-name
where gateway-profile-name is the name of the Gateway instance.
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10)Quit choice: [10] 7
-
Choose option 7 on the certificate administration menu.
All root CA certificates are displayed.
Listing All Certificates
You can view all certificates and their corresponding trust attributes by using the certificate administration script.
To List All the Certificates
-
As root, run the certadmin script.
portal-server-install-root /SUNWportal/bin/certadmin -n gateway-profile-name
where gateway-profile-name is the name of the Gateway instance.
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10)Quit choice: [10] 8
-
Choose option 8 on the certificate administration menu.
All CA certificates are displayed.
Printing a Certificate
You can print a certificate by using the certificate administration script.
To Print a Certificates
-
As root, run the certadmin script.
portal-server-install-root/SUNWportal/bin/certadmin -n gateway-profile-name
where gateway-profile-name is the name of the Gateway instance.
The certificate administration menu is displayed.
1) Generate Self-Signed Certificate 2) Generate Certificate Signing Request (CSR) 3) Add Root CA Certificate 4) Install Certificate From Certificate Authority (CA) 5) Delete Certificate 6) Modify Trust Attributes of Certificate (e.g., for PDC) 7) List Root CA Certificates 8) List All Certificates 9) Print Certificate Content 10)Quit choice: [10] 9
-
Choose option 9 on the certificate administration menu.
-
Enter the name of the certificate.
Chapter 11 Configuring the Netlet
This chapter describes configuring the Netlet attributes from the Sun Java System Portal Server administration console. All the attributes that can be configured at the organization level can also be configured at the user level. For more information on organization, role and user level attributes, see the Access Manager Administration Guide.
This chapter has the following sections:
Configuring the Netlet Attributes
You can perform the following tasks to configure the Netlet:
To Configure the Basic Attributes
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and select the Netlet tab.
-
Select a DN for a user or an organization from Select DN list or add a DN.
-
Modify the following attributes:
Attribute Name
Description
COS Priority
Specify value that is used to determine the inheritance of the attribute values. For more information on this attribute, see the Sun Java System Directory Server Administration Guide.
Launch Netlet Using
Select the mode either the Java Webstart or Applet option to start the Netlet service.
Default Loopback Port
Specify the port to be used on the local machine when applets are downloaded through Netlet. The default value of 58000 is used unless the value is overridden in the Netlet rules.
Enter the required port number.
Keep Alive Interval (seconds)
If the client is connecting to the Gateway through a web proxy, then idle Netlet connections are disconnected due to proxy time out. To prevent this, enter a value less than the proxy time-out.
-
Click Save to complete.
Configuring the Advanced Attributes
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and select the Netlet tab.
-
Select a DN for a user or an organization from Select DN list or add a DN.
-
Modify the following attributes:
Attribute Name
Description
Terminate Netlet at Portal Logout
Select Yes to ensure that all connections are terminated when a user logs out of the Portal Server. This ensures greater security. By default, this option is selected.
Select No to ensure that live Netlet connections are operational even after the user has logged out of the Portal Server desktop.
Note –When the No option is selected, users are not allowed to make new Netlet connections after logging out of the Portal Server. Only existing connections are preserved.
Re-authenticate for Connections
Select Yes to specify the port to be used on the local machine when applets are downloaded through Netlet. The default value of 58000 unless the value is overridden in the Netlet rules. By default, the No option is selected.
Display Warning Popup for Connections
Select Yes to display a warning popup dialog box on the user's desktop when other users are trying to connect to Netlet through the listen port and the user is running an application using Netlet. By default, the Yes option is selected.
Display Checkbox in Port Warning Dialog
Select Yes to display a warning popup dialog box on the users desktop when Netlet tries to connect to the destination host through an available port on the local machine, if its enabled in the administration console. By default, the Yes option is selected.
Netlet Rules
Create Netlet rules at a global level. These rules are inherited by any new organization that you create. For more information on creating, modifying, and deleting Netlet rules, see To Create, Modify, or Delete a Netlet Rule
Default Native VM Cipher
Select from the drop down box the default cipher for the Netlet rules. This is useful when using existing rules that did not include the cipher as a part of the rule. For more information, see the Backward Compatibility section.
Default Java Plugin Cipher
Select from the drop down box the default Java Plugin cipher. See Supported Ciphers for a list of supported ciphers.
Allowed/Denied Hosts
Select the host address check box and select host to either allow access based on the user or organization type and select either the Allow or Deny option from the drop-down box.
-
Click Add Row.
-
Enter the specify the fully qualified host address, for example: abc, type abc.sesta.com.
To add a new host:
Note –To delete an existing host: From the Host list, select the host and click Delete.
You can define access or deny to certain hosts to specific hosts for certain organizations, roles, or users. For example, you can set up the Allow list with five hosts to which the user can telnet. You can deny access to specific hosts within an organization. Specify a unique local port for each rule.
Note –An asterisk (*) in this field indicates that all the hosts in the specified domain are accessible. For example, if you specify *.sesta.com, all the Netlet targets within the sesta.com domain can be executed by the user. You can also specify a wild card IP address such as xxx.xxx.xxx.*.
Access/Deny Netlet Rules
Select the Nelet rule and select either the Allow or Deny option from the drop-down box.
You can define access to specific Netlet rules for certain organizations, roles or users.
You can deny access to specific Netlet rules for certain organizations, roles or users.
Note –An asterisk (*) in this field indicates that all the defined Netlet rules are available for the selected organization.
-
-
Click Save to complete.
To Create, Modify, or Delete a Netlet Rule
You can also create new rules or modify existing rules at the organization, role, or user levels. These rules are inherited by any new organization that you create.
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and select the Netlet tab.
-
Select a DN for a user or an organization from Select DN list or add a DN.
-
Under Advanced > Netlet Rules, click New Rule.
-
Enter the rule name in the Rule Name field.
-
Select Other choose from the list of available ciphers and under Encryption Ciphers list, select one or more encryption cipher or select Default to retain the default encryption cipher.
This is useful when using existing rules that did not include the cipher as a part of the rule. For information, see the Backward Compatibility section. For more information on ciphers, see Specify the Default Encryption Cipher.
-
Enter the URL to the application to be invoked in the Remote Application URL field.
-
Select the Client Port checkbox if an applet needs to be downloaded. Enter client port number, server host address, and server port number in the Client Port, Server Host, and Server Port field. Specify a unique local port for each rule.
By default, the Enable Download Applet box is disabled. Specify the applet details only if the applet needs to be downloaded from a host other than the Portal Server host. For more information, see Downloading an Applet From a Remote Host.
-
Select the Enable Extend Session checkbox to ensure that the Portal Server session time is extended while the Netlet session corresponding to this rule is running.
-
Under Map Local Port to Destination Server Port, do the following:
-
Enter the local port on which Netlet listens in the Local Port field.
For an FTP rule, the local port value must be 30021.
-
Enter an entry in the Destination Hosts field.
For a static rule, enter the host name of the target machine for the Netlet connection. For a dynamic rule, enter "TARGET".
-
Enter the port on the target host in the Destination Port field.
-
-
Click Save to complete.
The rule name is displayed in the Netlet home page.
Proxy Configuration for Netlet
The following attributes can be configured at the user level:
-
Browser proxy type
-
Browser proxy host
-
Browser proxy port
-
Browser proxy override list
If you do not specify these values in the administration console and Netlet is unable to determine the browser proxy setting, the user is asked for this information when a connection is being established through Netlet for the first time. This information is stored and used for future connections by the user.
Netlet fails to determine the browser proxy setting in the following scenarios:
-
The user has Internet Explorer 4.x, 5.x or 6.x with Java plug-in (version less then 1.4.0), has enabled the "Use Browser Settings" option in the Proxies tab of the Java Plug-in Control Panel, and has specified an add-on product or INS file in the "Use automatic configuration script" field in the Local Area Network Settings dialog of Internet Explorer.
-
The user has Netscape 6.2 with Java Plug-in (version 1.3.1_01 or greater) and has enabled the "Use Browser Settings" option in the Proxies tab of the Java Plug-in Control Panel.
In both these cases, Netlet may not be able to determine the browser settings, and hence the user is asked to supply the following information:
-
Browser proxy type
This attribute can take the values DIRECT or MANUAL. If the user chooses DIRECT from the drop-down list, Netlet connects directly to the gateway host.
-
Browser proxy host
Specify the required proxy host through which Netlet needs to connect.
-
Browser proxy port
Specify the port on the proxy host through which Netlet needs to connect.
-
Browser proxy override list (Comma separated)
Specify the hosts for which you do not want Netlet to connect through the proxy. This list can contain multiple comma-separated host names.
Chapter 12 Configuring Netlet With Private Domain Certificates
This chapter describes configuring the client browser’s Java Plug–in, so that Netlet can be used with PDC.
Note –
Only Virtual Machines (VMs) with JSSE support Netlet with PDC.
Configuring Netlet for PDC
Intro text should be here.
To Configure Netlet for PDC
-
Add com.iplanet.authentication.modules.cert.gwAuthEnable=yes anywhere in /ect/opt/SUNWam/config/AMConfig.properties file on the Portal Server machine.
-
Import the Required Certificates into the certificate database of the Gateway to be PDC enabled.
-
Import the Root CA certificate on the gateway machine.
-
Add the CA certificate to your gateway profile.
Tip –Create your own gateway profile to test PDC.
Perform the following to steps to add the certificate to your gateway profile.
-
Generate a Certificate Signing Request for submitting to the CA.
Perform the following steps to generate a Certificate Signing Request:
-
Submit the Certificate Signing Request to a CA and get it approved.
Tip –Save the certificate signing response after CA signing.
-
Import the CA approved Server Certificate.
Perform the following steps to import the Server Certificate:
-
Import the Root CA certificate to the Portal Server machine.
Chapter 13 Configuring Proxylet
This chapter describes configuring Proxylet from the Sun Java System Portal Server administration console.
This chapter contains the following sections:
Configuring the Proxylet Attributes
Proxylet can be configured to launch automatically when the user logs in by checking the Download Proxylet Applet Automatically checkbox under Deployment options. When the Download Proxylet Automatically checkbox is not selected, users can get Proxylet on-demand by clicking the Launch the Proxylet link in the Proxylet channel on the standard Portal Desktop.
To Configure the Proxylet Attributes
-
Log into Portal Server administration console as administrator.
-
Select the Secure Remote Access tab, and select the Proxylet tab.
-
Select an appropriate DN from the Select DN list box or add an existing DN for a specific user or an organization.
-
Under the Proxylet page, do the following:
Attribute Name
Description
COS Priority
Select the class of service for Proxylet traffic from a list of options.
Download Proxylet Applet Automatically
Click Yes to automatically download the Proxylet applet to the client machine. The following are the basic requirements to download the Proxylet applet:
Client machine can run a server application
Client machine Java version is 1.4 and above
The browser is IE 6.0 sp2 or Firefox 2.0
Correct browser permissions
Refresh Portal via Proxylet
Click Yes if you want to refresh your Portal desktop after the Proxylet is launched, and make the traffic to go through the Proxylet. "App Urls" won't be functional if both "Refresh portal after Proxylet Launch" and "Download Proxylet Applet Automatically" are enabled.
Launch Mode
Select Java Web Start or Applet.
Default Proxylet Applet Bind IP
Type the IP address where Proxylet binds and listens for requests from the browser.
Default Proxylet Applet Port
Type the port number where Proxylet listens for requests from a browser.
Automatic Proxy Configuration File Location
Type the location of the configuration file that contains proxy settings from the Proxy Auto Configuration (PAC) file or from the proxy configuration list.
-
In the Proxylet Rules option, do the following:
-
Specify the rules for the application to be launched through the Proxylet service.
-
Click Add.
-
Enter the domain name, for example, www.google.com in the Domain field.
-
Enter the host and corresponding port number for domain for Proxylet to process. This ensures that the Proxylet resolves the HTTP requests and the requests are not routed through the gateway.
-
-
Click Save to complete.
Configuring Applications to the Portal Desktop
Requests such as HTTP, FTP, and so on go through the Proxylet service. Proxylet rules allow the administrator to specify mappings based on protocol, host, or port to domains. With Proxylet rules your can specify the domain and proxy settings in the Proxy Auto Configuration (PAC) file. For example, you can create a rule so that all FTP traffic is routed through Netlet and all HTTP traffic is routed through Proxylet. You can configure predefined applications that need to be rendered through the Proxylet service. This can be done based on the user or organization preferences. Once the applications are added for Proxylet to process, the users desktop is easier to manage and provides better performance.
To Configure an Application to the Portal Desktop
Before You Begin
-
Ensure that the Proxylet option is enabled. For more information on enabling Proxylet, see the Gateway Profiles chapter.
-
Log into Portal Server administration console as administrator.
-
Select the Portal tab, and select the portal instance to modify.
The Desktop page is displayed.
-
Select an appropriate DN from the Select DN list box or add an existing DN for a specific user or an organization.
-
Click the Manage Containers and Channels link.
The Manage Containers and Channels page is displayed.
-
From the left pane, select Proxylet.
-
From the right pane, select the Appurls link.
-
In the Properties wizard, enter the application name and the value. Modify the properties of the application as required. For example, enter an appropriate name for the application, and http://www.example.com.
-
Click Close to complete.
The user or at the organization level can now view the application link on the Portal Desktop.
Launching Proxylet in Java Web Start or Applet Mode
You can start Proxylet either in the Java Web Start or Applet mode from the Portal Desktop.
To Launch Proxylet in Java Web Start or Applet Mode
-
Log onto the Portal Desktop as the proxylet user.
-
In the Front Page, go to the Proxylet channel and click the Edit icon.
-
From the Launch Mode list box, select the Java Web Start or Applet option.
-
Click Finished.
To invoke Proxylet, select the application from the Proxylet Channel. This launches the application in the Java Web Start or Applet mode.
-
If the Download Automatically is selected, click the application under the Proxylet channel.
-
Based on the user preferences, the Proxylet console is displayed depending on the selection of Java Web Start or Applet mode. Accept all certificates and continue to work on the application.
-
Chapter 14 Configuring NetFile
This chapter describes configuring NetFile from the Sun Java System Portal Server administration console.
This chapter contains the following section:
Configuration Tasks for NetFile
This section has the following tasks:
To Configure the Basic Options
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and select the Netfile tab.
-
Select a DN for a user or an organization from Select DN list or add a DN.
-
Modify the following attributes:
Attribute Name
Description
COS Priority
Specify value that is used to determine the inheritance of the attribute values. For more information on this attribute, see the Sun Java System Directory Server Administration Guide.
Domain/Host Preferences
Enter the default domain that NetFile requires to contact allowed hosts.
This default domain value is applicable only if the user does not specify a fully qualified host name while adding a host using NetFile.
Note –Ensure that the Default Domain field is not blank, and that it contains a valid domain name.
Default WINS/DNS Server
Enter the WINS/DNS server host address that NetFile uses to access Microsoft Windows hosts.
Note –A user can override this value by specifying a different value while adding a machine.
Host Detection Order
Use the Move Up and Move Down button to specify the host detention order.
Common Hosts
Enter either the host name or the fully qualified name and click Add.
If the host name that you have provided matches the host name configured by the user, the two sets of information are merged and the user-specified values override the values that you specified.
Configure a list of hosts to be available through NetFile to all remote NetFile users.
Note –For example, suppose you have configured 4 common hosts - sesta, siroe, florizon, and abc. A user configures 3 hosts out of which 2 are sesta and siroe. User-specified values override administrator-specified values in such conflict situations. florizon and abc are also listed in the user’s NetFile, and the user can carry out various operations on those hosts. In case you have listed florizon in the Denied Hosts List, florizon is listed in the user’s NetFile, but no operation can be carried out on florizon.
Host Type—If the user has already added a host that is listed in the Common Hosts list, the user setting takes precedence. If a conflict in the type exists, the shares added by the administrator are not added for that user. If the user and the administrator add the same share, the share is added, but the password set by the user takes precedence.
-
Click Save to complete.
To Configure the Access Privileges
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and select the Netfile tab.
-
Select a DN for a user or an organization from Select DN list or add a DN.
-
Click Access Privilege and modify the following attributes:
Attribute Name
Description
Access to Windows Hosts
Select the Allow checkbox to ensure that users have access to Windows Hosts.
By default, the Allow checkbox is selected.
Access to FTP Hosts
Select the Allow checkbox to ensure that users have access to FTP Hosts.
Access to NFS Hosts
Select the Allow checkbox to ensure that users have access to NFS Hosts.
Access to Netware Hosts
Select the Allow checkbox to ensure that users have access to Netware Hosts.
-
Click Save to complete.
To Configure the Host Preferences
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and select the Netfile tab.
-
Select a DN for a user or an organization from Select DN list or add a DN.
-
By default, users are allowed to access all the hosts through NetFile because of the * entry in the Allow/Deny hosts list. If you want to change that, remove the * entry and specify only those hosts to which users need to have access through NetFile, in this list. Alternatively, you can keep the * entry here, and specify the hosts to which you want to deny access in the Denied Hosts list. In that case, all the hosts except the ones specified in the Denied Hosts list are allowed access.
Note –If you deny access to a host, and a user has already added this host in the NetFile window, the denied host continues to be displayed in the NetFile window of the user. But the user is not be able to carry out any operations on the host. In NetFile Java2, denied hosts, if displayed in the application, are marked with a red cross to indicate that they are inaccessible. If both the Allowed Hosts and Denied Hosts lists are blank, access is not allowed to any host.
-
Click Save to complete.
To Configure the Operation Preferences
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and select the Netfile tab.
-
Select a DN for a user or an organization from Select DN list or add a DN.
-
Modify the following attributes:
Attribute Name
Description
Default Compression Type
Select ZIP or GZ from the drop down box as the default file compression format.
Default Compression Level
Select the default compression level from the drop down box. The default is 6.
Temporary Directory Location
Enter the location for the temporary files. The specified temporary directory is created if it does not exist on the server.
A temporary directory is required some file operations such as mailing files. The default temporary directory is /tmp. The temporary files are deleted after the required operation has completed.
Note –Ensure that the ID with which the web server is running (such as nobody or noaccess) has rwx permissions for the specified directory. Also ensure that the ID has rx permissions for the entire path to the required temporary directory.
Tip –You may want to create a separate temporary directory for NetFile. If you specify a temporary directory that is common to all modules of the Portal Server, the disk may quickly run out of space. A few operations in NetFile, such as mailing files, do not work if the temporary directory has no space.
File Upload Limit (MB)
Enter the maximum size of the files that can be uploaded in this field. The default value is 5MB.
When the size of the file being uploaded exceeds the limit specified here, an error message is displayed and the file is not uploaded. If you enter an invalid value, NetFile resets the value to the default value. You can specify different file upload size limits for different users.
Search Directories Limit
Enter the maximum number of directories that can be searched in a single search operation. This limit helps reduce network clogging and increases the speed of access if a number of users are logged in simultaneously. The default value is 100.
Suppose a user has a directory called A. Assume that A has 100 subdirectories. If you specify the maximum directories to be searched as 100, the search operation goes through directory A and stops. The search does not proceed through the other directories in the users machine since the limit of 100 was reached with directory A. The search results accumulated until the search limit is reached are displayed to the user along with an error message stating that the search exceeded its limit. To continue the search, the user must manually restart the search at the next directory. The search operation is carried out in a depth-first manner. This means that the search operation is carried out in all the subdirectories of the directory that the user selected, before moving on to the next directory.
-
Click Save to complete.
To Configure the Operation Privileges
You can allow or deny permission for users to perform the following tasks from remote hosts.
-
Log onto the Portal Server administration console as administrator.
-
Select the Secure Remote Access tab and select the Netfile tab.
-
Select a DN for a user or an organization from Select DN list or add a DN.
-
Modify the following attributes:
Attribute Name
Description
File Rename
Select the Allow checkbox to enable users to rename files. This option is selected by default.
File/Folder Deletion
Select the Allow checkbox to enable users to delete files and directories. This option is selected by default.
File Upload
Select the Allow checkbox to enable users to upload files. This option is selected by default.
File/Folder Download
Select the Allow checkbox to enable users to download files or directories. This option is selected by default.
File Search
Select the Allow checkbox to enable users to perform file search operations. This option is selected by default.
File Mail
Select the Allow checkbox to enable users to access to mail. This option is selected by default.
File Compression
Select the Allow checkbox to enable users to choose the compression type. This option is selected by default.
Changing User Id
Select the Allow checkbox to enable users to change their user ID. Users can use different IDs to connect to hosts using NetFile.
In a large organization, users may have multiple user IDs. You may want to restrict users to use a single user ID. In that case, you can disable the Allow Changing User ID option. This prevents all the users in the specific organization from changing their user ID, and limits them to using a single ID (the desktop login ID) to connect to hosts using NetFile. In another situation, a user may have different login IDs on different machines, in which case, you may want to allow the user to change the ID as required.
Changing Microsoft Windows Domains
Select the Allow checkbox to enable users to change the default Microsoft Windows domain host. This option is selected by default.
When the user specifies a domain name, the username and password for that domain also needs to be specified. If the username and password for the host needs to be used, the user needs to remove the domain from the User Domain name field.
Note –When the any of the above options are not selected, the changes takes effect only after the user logs onto Portal Server desktop again.
-
Click Save to complete.
Chapter 15 Configuring Secure Socket Layer Accelerators
This chapter describes configuring various accelerators for Sun Java System Portal Server Secure Remote Access.
This chapter contains the following sections:
Introduction to Accelerators
External accelerators are dedicated hardware co-processors that off-load the Secure Socket Layer (SSL) functions from a server\qs CPU, thereby freeing the CPU to perform other tasks and increasing the processing speed for SSL transactions.
Sun Crypto Accelerator 1000
The Sun™ Crypto Accelerator 1000 (Sun CA1000) board is a short PCI board that functions as a cryptographic co-processor to accelerate public key and symmetric cryptography. This product has no external interfaces. The board communicates with the host through the internal PCI bus interface. The purpose of this board is to accelerate a variety of computationally intensive cryptographic algorithms for security protocols in eCommerce applications.
Many critical cryptographic functions, such as RSA [7] and Triple-DES (3DES) [8], can be off-loaded from an application to the Sun CA1000 and performed in parallel. This frees the CPU to perform other tasks, increasing the processing speed for SSL transactions.
See To Configure Crypto Accelerator 1000 for steps.
Enable Crypto Accelerator 1000
Ensure that Portal Server Secure Remote Access has been installed, and a gateway server certificate (self-signed or issued by any CA) has been installed. See the Chapter 10, Working with Certificates for details.
Enable Crypto Accelerator 1000 is a checklist to help you keep track of the required information before installing the SSL Accelerator.lists the Crypto Accelerator 1000 parameters and values.
Table 15–1 Crypto Accelerator 1000 Installation Checklist|
Parameter |
Value |
|---|---|
|
SRA installation base directory |
/opt |
|
SRA certificate database path |
/etc/opt/SUNWportal/cert/default |
|
SRA server certificate nickname |
server-cert |
|
Realm |
sra-keystore |
|
Realm user |
crypta |
To Configure Crypto Accelerator 1000
-
Follow the instructions in the user's guide to install the hardware. See:
http://www.sun.com/products-n-solutions/hardware/docs/pdf/816-2450-11.pdf
-
Install the following packages from the CD.
SUNWcrypm, SUNWcrypu, SUNWcrysu, SUNWdcar, SUNWcrypr, SUNWcrysl, SUNWdcamn, SUNWdcav
-
Install the following patches. (You can get them from the http://sunsolve.sun.com)
110383-01, 108528-05, 112438-01
-
Make sure you have the tools pk12util and modutil.
These tools are installed under /usr/sfw/bin. If the tools are not available in the /usf/sfw/bin directory, you need to manually add the SUNWtlsu package from the Sun Java System distribution media:
Solaris_[sparc/x86]/Product/shared_components/
-
Create the slots file:
vi /etc/opt/SUNWconn/crypto/slots
and put "crypta@sra" as the first and only line in the file.
-
Create and set a realm.
-
Create a user:
-
Login as the user you created.
secadm{root@sra}> login user=crypta
Password:
secadm{crypta@sra}> show key
No keys exist for this user.
-
Load the Sun Crypto module.
The environment variable LD_LIBRARY_PATH must point to /usr/lib/mps/secv1/
Type:
modutil -dbdir /etc/opt/SUNWportal/cert/default -add "Sun Crypto Module" -libfile /opt/SUNWconn/crypto/lib/libpkcs11.so
Use the following command to verify that this module is loaded:
modutil -list -dbdir /etc/opt/SUNWportal/cert /default
-
Export the gateway certificate and the key to the "Sun Crypto Module".
The environment variable LD_LIBRARY_PATH must point to /usr/lib/mps/secv1/
Type:
pk12util -o servercert.p12 -d /etc/opt/SUNWportal/cert/default -n server-cert
pk12util -i servercert.p12 -d /etc/opt/SUNWportal/cert/default -h "crypta@sra"
Now run the show key command:
secadm{crypta@sra}> show key
You should see two keys for this user.
-
Change the nickname in the /etc/opt/SUNWportal/cert/default/.nickname file.
vi /etc/opt/SUNWportal/cert/default/.nickname
replace the server-cert with crypta@sra:server-cert
-
Enable ciphers for acceleration.
SUN CA1000 accelerates RSA functions but supports acceleration only for DES and 3DES ciphers.
-
Modify the /etc/opt/SUNWportal/platform.conf.gateway-profile-name to enable the accelerator:
gateway.enable.accelerator=true
-
From a terminal window, restart the gateway:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
Note –Gateway binds to a plain ServerSocket (non SSL) on the port mentioned as https port in the gateway profile.
No SSL encryption or decryption is done on the incoming client traffic. This is done by the accelerator.
PDC is not be functional in this mode.
Sun Crypto Accelerator 4000
The Sun™ Crypto Accelerator 4000 board is a Gigabit Ethernet-based network interface card that supports cryptographic hardware acceleration for IPsec and SSL (both symmetric and asymmetric) on Sun servers.
In addition to operating as a standard Gigabit Ethernet network interface card for unencrypted network traffic, the board contains cryptographic hardware to support a higher throughput for encrypted IPsec traffic.
The Crypto Accelerator 4000 board accelerates cryptographic algorithms in both hardware and software. It also supports bulk encryption for ciphers DES and 3DES.
See To Configure Crypto Accelerator 4000 for steps.
Enable Crypto Accelerator 4000
Ensure that SRA has been installed and a gateway server certificate (self-signed or issued by any CA) has been installed. The following checklist helps you keep track of the required information before installing the SSL Accelerator.
Enable Crypto Accelerator 1000 lists the Crypto Accelerator 4000 parameters and values.
Table 15–2 Crypto Accelerator 4000 Installation Checklist|
Parameter |
Value |
|---|---|
|
Portal Server Secure Remote Access installation base directory |
/opt |
|
SRA instance |
default |
|
SRA certificate database path |
/etc/opt/SUNWportal/cert/default |
|
SRA server certificate nickname |
server-cert |
|
CA4000 keystore |
srap |
|
CA4000 keystore user |
crypta |
To Configure Crypto Accelerator 4000
-
Follow the instructions in the user\qs guide to install the hardware and the software packages. See:
http://www.sun.com/products-n-solutions/hardware/docs/pdf/816-2450-11.pdf
-
Install the following patch. (You can get them from the http://sunsolve.sun.com): 114795
-
Make sure that you have the tools certutil, pk12util and modutil.
These tools are installed under /usr/sfw/bin
If the tools are not available in the /usf/sfw/bin directory, you need
to manually add the SUNWtlsu package from the Sun Java System distribution media:
Solaris_[sparc/x86]/Product/shared_components/
-
Initialize the board.
Run the /opt/SUNWconn/bin/vcadm tool to initialize the crypto board and set the following values.
Initial Security Officer Name: sec_officer
Keystore name: sra-keystore
Run in FIPS 140-2 Mode: No
-
Create a user.
vcaadm{vca0@localhost, sec_officer}> create user
New user name: crypta
Enter new user password:
Confirm password:
User crypta created successfully.
-
Map token to the key store.
vi /opt/SUNWconn/cryptov2/tokens
and append sra-keystore to the file.
-
Enable bulk encryption.
touch /opt/SUNWconn/cryptov2/sslreg
-
Load the Sun Crypto module.
The environment variable LD_LIBRARY_PATH must point to /usr/lib/mps/secv1/
Type:
modutil -dbdir /etc/opt/SUNWportal/cert/default -add "Sun Crypto Module" -libfile /opt/SUNWconn/cryptov2/lib/libvpkcs11.so
You can verify that this module is loaded using the following command:
modutil -list -dbdir /etc/opt/SUNWportal/cert/default
-
Export the gateway certificate and the key to the "Sun Crypto Module".
The environment variable LD_LIBRARY_PATH must point to /usr/lib/mps/secv1/
pk12util -o servercert.p12 -d /etc/opt/SUNWportal/cert/default -n server-cert
pk12util -i servercert.p12 -d /etc/opt/SUNWportal/cert/default -h "sra-keystore"
You can verify that the key has been exported using the following command:
certutil -K -h "sra-keystore" -d /etc/opt/SUNWportal/cert/default
-
Change the nickname in the /etc/opt/SUNWportal/cert/default/.nickname file:
vi /etc/opt/SUNWportal/cert/default/.nickname
replace the server-cert with sra-keystore:server-cert
-
Enable the ciphers for acceleration.
-
From a terminal window, restart the gateway:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
The Gateway prompts you to enter the keystore password.
Enter Password or Pin for "sra-keystore":crypta:crytpa-password
Note –Gateway binds to a plain ServerSocket (non SSL) on the port mentioned as https port in the gateway profile.
No SSL encryption or decryption is done on the incoming client traffic. This is done by the accelerator.
PDC is not be functional in this mode.
External SSL Device and Proxy Accelerators
An external SSL device can run in front of Portal Server Secure Remote Access (SRA) in open mode. It provides the SSL link between the client and SRA.
The following tasks can be performed:
To Enable an External SSL Device Accelerator
-
Ensure that SRA has been installed and a gateway is running in open mode (HTTP mode).
-
Enable an HTTP Connection.
The table lists the external SSL device and proxy accelerator parameters and values.
Parameter
Value
SRA instance
default
Gateway Mode
http
Gateway Port
880
External Device/Proxy Port
443
To Configure External SSL Device Accelerators
-
Follow the instructions in the user guide to install the hardware and software packages.
-
Install the required patches, if any.
-
Configure a gateway instance to use HTTP.
-
Enter the following values in the platform.conf file:
gateway.enable.customurl=true
gateway.enable.accelerator=true
gateway.httpurl=https://external-device-URL:port-number
-
Gateway notification can be configured in two ways:
-
When the Access Manager can contact the gateway machine at port 880 (Session notifications are in HTTP), enter values in the platform.conf file.
vi /etc/opt/SUNWportal/platform.conf.default
gateway.protocol=http
gateway.port=880
-
When the Access Manager can contact the external device/proxy at port 443 (Session notifications are be in HTTPS), enter values in the platform.conf file.
vi /etc/opt/SUNWportal/platform.conf.default
gateway.host=External Device/Proxy Host Name
gateway.protocol=https
gateway.port=443
-
-
-
Make sure that the SSL device/proxy is up and running and configured to tunnel the traffic to the gateway port.
-
From a terminal window, restart the gateway:
./psadmin start-sra-instance -u amadmin -f passwordfile -N profilename -t gateway
- © 2010, Oracle Corporation and/or its affiliates