You can enable form-fill single sign-on functionality for an application with the Access Portal Service.
The following topic describes how to enable form-fill single sign-on functionality:
After you create the application policy, you must add a proxy-enabled application URL to the policy to enable form-fill functionality. Once configured, you must publish the policy to the repository and test it to ensure that form-fill single-sign on is functioning as expected.
The following topics describe how to configure a form-fill application policy:
You can create a Form-Fill application policy using Oracle Enterprise Single Sign-On Administrative Console.
To create:
Launch the Oracle Enterprise Single Sign-On Administrative Console.
In the left-hand tree right-click the Applications node and select New Web Application from the context menu.
In the dialog that appears, enter a descriptive name and click Next. This will appear as the application policy name in Oracle Access Manager Console.
In the screen that appears, select the desired form type and click OK.
In the screen that appears, enter the URL of the target application.
Click Detect Fields.
The application's logon form appears in the window and the appropriate fields are automatically detected and configured. Verify that:
The fields have been detected and configured correctly in the field list.
A Submit Button is detected. If no Submit button is defined, Silent Credential Capture will not function.
For more information on creating application policies (also known as templates), see the guide Creating and Configuring Logon Manager Application Templates.
Click OK to save the application policy.
In the General tab, provide optional metadata describing the application (this metadata will appear in the Access Portal reference application or another user interface of your choice, if parsed):
Description – a meaningful description of the application for the user.
Reference – internal reference describing the version/variant of the application template.
Category – the category under which the application will appear in the Access Portal reference application; for example, "Finance," "Development," and so on.
Icon Image URL – URL to the icon image that will appear next to the application entry in the Access Portal reference application.
Logo Image URL – URL to the full-size application logo image that will appear in the Access Portal reference application.
Vendor – the vendor of the application.
Administrator – contact information for the application's administrator within your organization.
Select the desired users and/or user groups to whom this template will be available:
Select the Security tab.
Select the Access Portal Service repository from the Directory drop-down menu.
Click Add.
In the dialog that appears, enter the name of the target user or group.
Click Check Names to verify the user or group exists in the directory; if you receive an error, re-enter the name and try again.
Click OK to save your changes.
You can add a proxy-enables URL to a Form Fill application policy from the policy’s General tab.
To add:
The Access Portal Service allows you to configure mock credential field values which will be displayed in the browser during injection for each configured field to prevent man-in-the-middle snooping.
To configure mock credential field values:
If you want to prevent the user from seeing or altering the injected credentials, you can configure the Access Portal Service to mask the entire form from view using an overlay (a solid color or an image of your choice).
Keep in mind that:
If no application credentials exist for the target form, the form will not be masked even if the mask has been configured, and the user will be able to enter their own credentials to continue with the form.
If more than one set of credentials exists for the target form, the Logon Chooser dialog will appear, allowing the user to choose the desired credentials to inject.
To configure form masking:
You can publish a policy to the repository.
To publish a policy to the repository:
Instead of publishing the policy to the repository, you can import it in the Oracle Access Manager Console to further edit its basic settings there.
If you have already published it to the repository, you can skip this step, as the Oracle Access Manager console will retrieve it from the repository and display it in its policies list. If you modify the policy in the Oracle Access Manager console and then decide to edit it in the Enterprise Single Sign-On Administrative Console, you will need to manually pull down the updated version from the Access Portal Service repository.
Note:
Oracle recommends creating and configuring the policy in the Enterprise Single Sign-On Administrative Console as not all Oracle Access Portal features can be configured in the Oracle Access Manager Console. Additionally, you must select the Unicode encoding when saving the exported .INI file; the Oracle Access Management console does not support importing non-Unicode files.
To optionally import a policy in the Oracle Access Manager:
Start the Enterprise Single Sign-On Administrative Console and import the desired policy (template) from the repository.
Export the policy to a file:
From the File menu, select Export.
In the "Export to .INI File" dialog that appears, select the policy from the list and click OK.
In the dialog that appears, select Unicode from the Encoding drop-down list, provide the desired path and name for the exported file, and click Save.
Import the template file into Oracle Access Manager:
Log on to the Oracle Access Manager console.
In the "Access Manager" section of the page that appears, click Applications.
In the toolbar above the application list, click Import (blue down-arrow).
In the "Import Applications" pop-up that appears, click Browse.
In the dialog that appears, navigate to the policy file, and click Open.
Click OK in the "Import Applications" pop-up.
In the list of applications to import displayed by the pop-up, select the desired application and click Import.
In the application configuration page that appears, verify that the configuration settings in each tab have been properly carried over and make any changes if necessary. When you have finished, click Save.
The imported application policy appears in the application list.
Configure the EssoDirectSubmit Server Application Function (SAF) to match with the URL path of the targeted application’s login page.
You must adhere to some basic guidelines for creating any proxy rules that are necessary to intercept the user connections to the target application and redirect them to pass through the Webgate plugin.
For in-depth information on configuring Oracle Traffic Director, please see the Oracle Traffic Director Administrator's Guide.
Since the user connection requested is intercepted by Oracle Traffic Director and redirected to the origin server, all resources referenced within the page's code must have their path rewritten to point to the Oracle Traffic Director origin server instead of the original host; otherwise, those elements will not be loaded and the page will display improperly and likely not function as intended.The following topics provide guidelines for the types of resources that must be rewritten for the page to function properly after proxy redirection:
You need to configure Oracle Traffic Director proxy rules for an Oracle Access Portal Application that resides on a single host server.
Any applications that are hosted on multiple servers are not covered. Working knowledge of Oracle Traffic Director concepts and configuration procedures is assumed. To add an Oracle Access Portal application to Oracle Traffic Director:
Select the protocol(s) required by the origin server application pages (home, logon, post URL, landing page) from the following scenarios:
HTTP only. All of the application's pages are served over HTTP.
HTTPS only. All of the application's pages are served over HTTPS.
HTTP pre-logon/HTTPS post-logon. Home and login pages are served over either HTTP or HTTPS; however, the landing page for successfully authenticated users is served over HTTPS.
HTTP with POST over HTTPS. All of the pages are served over HTTP but the logon form POST transaction occurs over HTTPS.
For proper security, Oracle highly recommends matching the proxy listener protocols with those of their respective origin server pages when configuring the proxy rules. For example, do not configure an HTTP proxy listener for a page that is originally served over HTTPS.
On the other hand, if you want to configure an HTTPS listener for a page that is originally server over HTTP, you will need to configure additional proxy rules - for more information, see the Oracle Traffic Director documentation.
Create the appropriate listeners for each protocol and assign them to the target virtual server.
Create the corresponding origin server pools for each protocol. Include the protocol and URI of the origin application to clearly distinguish between each pool. For example:
URI: http://www.originapp.com
Pool name: origin-server-pool-http-www-originapp.com
URI: https://www.originapp.com
Pool name: origin-server-pool-https-www-originapp.com
Create a route for the origin application using the New Route Wizard as follows:
Select the origin server pool you created in step 3. If you created more than one origin server pool, select the HTTP (non-SSL) pool.
Create a URI route condition for the application - this will be the path at which your application will be accessible. Oracle recommends setting this value to the name of your origin application or using the condition builder. This path will be called the PROXY_MAP
later in this procedure.
For example: $uri =~ "^/originapp"
Complete the remaining steps in the wizard to finish creating the route.
In the list of routes, select the route you created in step 4 and open the Advanced Settings section.
In the Rewrite Headers field, add the host header for the origin application in the following format:
location,content-location,host
Apply the following route template and replace the variables as described below:
#PROXY_MAP#
- path to the proxied application (reverse map of the From-URI value) from step 4b. For example: originapp
.
#OTD_HTTP#
- port of the application's HTTP listener.
For example: 80
#OTD_HTTPS#
- port number of the application's HTTPS listener.
For example: 443
#ORIGIN_HOST#
- host name of the origin server pool to rewrite.
For example: www.originapp.com
#DOCUMENT-DOMAIN#
- domain attribute in which cookie values can be specified.
For example: originapp.com
#Instructs OTD to map the incoming URI from the user's browser to the root path of the origin server. OTD also uses these values to create a reverse mapping to rewrite cookie paths.
It is not usually necessary to change the value of the to parameter.
NameTrans fn="map" to="/" from="/#PROXY_MAP#
" #Rewrite the https referer header
<If defined $referer and $referer =~ "https://.*?\\.us\\.oracle\\.com:#OTD_HTTPS#/#PROXY_MAP#/(.*)$">
AuthTrans fn="set-variable" set-headers="referer=https://#ORIGIN_HOST#/$1"
</If>
#Rewrite the http referer header
<If defined $referer and $referer =~ "http://.*?\\.us\\.oracle\\.com:#OTD_HTTP#/#PROXY_MAP#/(.*)$">
AuthTrans fn="set-variable" set-headers="referer=http://#ORIGIN_HOST#/$1"
</If>
#Remove potential headers that may interfere with mixed proxy content
<If defined $srvhdrs{'content-security-policy'}>
Output fn="sed-response-header" name="content-security-policy" sed="s|script-src |script-src 'self' |g"
</If>
<If defined $srvhdrs{'access-control-allow-origin'}>
Output fn="set-variable" remove-srvhdrs="access-control-allow-origin"
</If>
#rewrite the location header when origin server is redirecting from HTTP to HTTPS
<If defined $srvhdrs{'location'} and $srvhdrs{'location'} =~ "^https://#ORIGIN_HOST#(:\\d+)?(/?.*)" >
Output fn="set-variable" $srvhdrs{'location'}="https://$urlhost:#OTD_HTTPS#/#PROXY_MAP#$2"
</If>
<If defined $srvhdrs{'location'} and $srvhdrs{'location'} =~ "^http://#ORIGIN_HOST#(:\\d+)?(/?.*)" >
Output fn="set-variable" $srvhdrs{'location'}="http://$urlhost:#OTD_HTTP#/#PROXY_MAP#/$2"
</If>
#Insert the Dynamic Proxy Script parameters
AuthTrans fn="set-variable" insert-vars="DYNAMIC-PROXY-ENABLE=on" insert-vars="DYNAMIC-PROXY-MAP-TO=/#PROXY_MAP#" insert-vars="DYNAMIC-PROXY-MAP-FROM=/" insert-vars="DYNAMIC-PROXY-HTTPS=#OTD_HTTPS#" insert-vars="DYNAMIC-PROXY-HTTP=#OTD_HTTP#" insert-vars="DYNAMIC-PROXY-IGNORE-PATHS="
#Map all src,href,action,background,data-li-search-action and data-li-advanced-link attributes found in html content to the proxied path
Output fn="insert-filter" filter="sed-response" sed="s|\\( src=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( src=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( href=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( href=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( action=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( action=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( background=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( background=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( data-li-advanced-link=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( data-li-advanced-link=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" sed="s|\\( data-li-search-action=\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2 oap=\"true\"|g" sed="s|\\( data-li-search-action=\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2 oap='true'|g" append-newline-at-end="false" type="(text/html*|text/xml*)"
#Map CSS attributes to the proxied path
Output fn="insert-filter" filter="sed-response" sed="s|url(\"/\\([^/][^\"]\\)|url(\"/#PROXY_MAP#/\\1|g" sed="s|url('/\\([^/][^']\\)|url('/#PROXY_MAP#/\\1|g" sed="s|url(/\\([^/][^)]\\)|url(/#PROXY_MAP#/\\1|g" type="(text/css*|text/html*)" append-newline-at-end="false"
#Rewrite full URL links to the OTD proxied host/port. These sed expressions keep the existing protocols in the URL.
Output fn="insert-filter" filter="sed-response" sed="s|http://#ORIGIN_HOST#:80|http://$urlhost:#OTD_HTTP#/#PROXY_MAP#|g" sed="s|http://#ORIGIN_HOST#|http://$urlhost:#OTD_HTTP#/#PROXY_MAP#|g" sed="s|https://#ORIGIN_HOST#:443|https://$urlhost:#OTD_HTTPS#/#PROXY_MAP#|g" sed="s|https://#ORIGIN_HOST#|https://$urlhost:#OTD_HTTPS#/#PROXY_MAP#|g" sed="s|https:\\\\/\\\\/#ORIGIN_HOST#|https:\\\\/\\\\/$urlhost:#OTD_HTTPS#\\\\/#PROXY_MAP#|g" sed="s|http:\\\\/\\\\/#ORIGIN_HOST#|http:\\\\/\\\\/$urlhost:#OTD_HTTP#\\\\/#PROXY_MAP#|g" type="(text*|application*)" sed="s|//#ORIGIN_HOST#|https://$urlhost:#OTD_HTTPS#/#PROXY_MAP#|g" append-newline-at-end="false"
#Sanitize any illegal javascript domain values for our proxied host
Output fn="insert-filter" filter="sed-response" sed="s|\\(document.domain=\"\\)#DOCUMENT_DOMAIN#\"|\\1$urlhost\"|g" sed="s|\\(document.domain='\\)#DOCUMENT_DOMAIN#'|\\1$urlhost'|g" sed="s|\\(document.domain = \"\\)#DOCUMENT_DOMAIN#\"|\\1$urlhost\"|g" sed="s|\\(document.domain = '\\)#DOCUMENT_DOMAIN#'|\\1$urlhost'|g" type="(text*|application*)" append-newline-at-end="false"
#Attempt to rewrite any javascript page redirects
Output fn="insert-filter" filter="sed-response" sed="s|\\(location.replace(\\)\"/\\([^/][^\"]*\"\\)|\\1\"/#PROXY_MAP#/\\2|g" sed="s|\\(location.replace(\\)'/\\([^/][^']*'\\)|\\1'/#PROXY_MAP#/\\2|g" sed="s|\\(location.href =\"\\)\\(/[^/][^\"]*\"\\)|\\1/#PROXY_MAP#\\2|g" sed="s|\\(location.href ='\\)\\(/[^/][^']*'\\)|\\1/#PROXY_MAP#\\2|g" type="(text*|application*)" append-newline-at-end="false"
#Attempt to rewrite any JSON objects that appear as URI paths
.Output fn="insert-filter" filter="sed-response" sed="s|\\(:\"\\)\\(/[^/][^\"]*\"\\)|\\1/#PROXY_MAP#\\2|g" sed="s|\\(:'\\)\\(/[^/][^\']*'\\)|\\1/#PROXY_MAP#\\2|g" type="application/json*" append-newline-at-end="false"
#rewrite any javascript page redirects common in ADF applications
Output fn="insert-filter" filter="sed-response" sed="s|\\(redirect url=\"/\\)|\\1#PROXY_MAP#/|g" sed="s|<redirect>/\\([^/][^<]*\\)|<redirect>/#PROXY_MAP#/\\1|g" type="text/xml*"
#Remove any domain attributes from the cookie header. This will force the browser to use the otd host name as a default
Output fn="sed-response-header" name="set-cookie" sed="s|domain=#DOCUMENT_DOMAIN#||g" sed="s|Domain=#DOCUMENT_DOMAIN#||g" sed="s|domain=.#DOCUMENT_DOMAIN#||g" sed="s|Domain=.#DOCUMENT_DOMAIN#||g" sed="s|domain=.#ORIGIN_HOST#||g" sed="s|Domain=.#ORIGIN_HOST#||g"
Paste the generated template into the target route (e.g. originapp
) section in the $SERVER-obj.conf file
.
If you created one or more HTTPS listeners in step 2, make the following changes in the target route (e.g., originapp
) section of the $SERVER-obj.conf
file:
Locate the following statement:
Route fn="set-origin-server" origin-server-pool= "origin-server-pool-http-www-originapp-com" rewrite-host="true"
Add the following security rule directly above the statement listed in step 9a:
<If $security>
Route fn="set-origin-server" origin-server-pool="origin-server-pool-https-www-originapp-com" rewrite-host="true"
</If>
Reconfigure the server.
HTTP request and response headers contain parameters that must be rewritten to point to the Oracle Traffic Director origin server. Oracle Traffic Director can rewrite basic location headers that contain the origin server host name and exact protocol, or a relative path.
A typical HTTP request header appears as follows:
GET /web/en-US/default.aspx HTTP/1.1
Host: www.oracle.com
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html, application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: http://www.oracle.com/web/en-US/default.aspx ?root=1
Connection: keep-alive
This example header contains the following parameters that require path rewriting:
GET
- contains the path of the requested page relative to the Web root, plus HTTP protocol version.
For example: GET /web/en-US/default.aspx HTTP/1.1
An example proxy rule for rewriting the GET
parameter:
NameTrans fn="map" to="/" from="/myLocalPath
"
Host
- contains the URL of the page host.
For example: www.oracle.com
An example proxy rule for rewriting the Host
parameter:
Route fn="set-origin-server" origin-server-pool="myoriginserverpool"
rewrite-host="true"
Referer
- contains the URL of the page that referred the request. For example: http://www.oracle.com/web/en-US/default.aspx ?root=1
An example rule for rewriting the Referer
parameter:
<If defined $referer and $referer =~ "https://myoriginserver.oracle.com/myLocalPath/(.*)$"
>
AuthTrans fn="set-variable" set-headers="referer=https://www.oracle.com/$1"
</If>
Note:
Since Web applications vary widely, in addition to the above examples, you must examine your HTTP headers to account for any other parameters referencing a URL or a relative path.
A rewritten version of our example header would then look as follows:
GET /myLocalPath/web/en-US/default.aspx HTTP/1.1
Host: myoriginserver.oracle.com:8484
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:23.0) Gecko/20100101 Firefox/23.0
Accept: text/html, application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
Accept-Language: en-US,en;q=0.5
Accept-Encoding: gzip, deflate
Referer: https://myoriginserver.oracle.com:8484/myLocalPath/ web/en-US/default.aspx?root=1
Connection: keep-alive
Oracle Traffic Director can not handle location redirects to another origin server. For example, if a logon page hosted on one host redirects the user to a page on another host upon successful logon, you must configure the rewriting rules for this remapping manually. For example:
<Object name="route-oracle-travel-sso">
<If defined $srvhdrs{'location'} and $srvhdrs{'location'} =~ "(http|https)://portal.myapplication.com(.*)$">
Output fn="set-variable" $srvhdrs{'location'}="https://myoriginserver.oracle.com:8484/travel-portal$2"
</If>
Output fn="sed-response-header" name="set-cookie" sed="s|path=/travel-sso/|path=/|g"
</Object>
<Object name="route-travel-portal">
Route fn="set-origin-server" origin-server-pool="origin-server-portal-oracle-travle" rewrite-host="true"
</Object>
The path and domain parameters in cookies need to be rewritten to point to the Oracle Traffic Director origin server instead of the target application host.
For example:
Set-cookie: v1st=1666B5EACC906D6; path=/; expires=Wed, 19 Feb 2020 14:28:00 GMT; domain=.www.oracle.com
Must become:
Set-cookie: v1st=1666B5EACC906D6; path=/myLocalPath/; expires=Wed, 19 Feb 2020 14:28:00 GMT; domain=.myoriginserver.oracle.com
When configuring cookie rewriting rules, note the following:
Oracle Traffic Director cannot rewrite wildcarded domains, such as .oracle.com
. A target host name must be specified, for example: .www.oracle.com
.
If your application shares cookies across multiple domains, you must create separate cookie rewriting rules for each domain.
You must strip out the Oracle Authentication Manager cookie from the cookie set request, as it interferes with certain Web applications, such as Dropbox.
Example rule for stripping out the Oracle Authentication Manager cookie:
AuthTrans fn="sed-request-header" name="cookie" sed="s|OAMAuthnCookie[^;]*;| |g" sed="s|OAMRequestContext[^;]*;| |g"
You must strip out Oracle Authentication Manager headers before sending them to the application host.
Oracle Traffic Director does not directly provide the means to rewrite host names and resource paths within the HTML code of the target page.
You must use sed expressions to rewrite those values. Common HTML elements whose values will require rewriting include src
, href
, and action
.
Example sed rule set for rewriting the src
, href
, and action
elements:
Output fn="insert-filter" filter="sed-response" sed="s|\\(src\\)=\"/\\([^\"|^/]\\)|\\1=\"/myLocalPath/\\2|g" sed="s|\\(src\\)='/\\([^'|^/]\\)|\\1='/myLocalPath/\\2|g" sed="s|\\(href\\)=\"/\\([^\"|^/]\\)|\\1=\"/myLocalPath/\\2|g" sed="s|\\(href\\)='/\\([^'|^/]\\)|\\1='/myLocalPath/\\2|g" sed="s|\\(action\\)=\"/\\([^\"|^/]\\)|\\1=\"/myLocalPath/\\2|g" sed="s|\\(action\\)='/\\([^'|^/]\\)|\\1='/myLocalPath/\\2|g" type="text/html*"
Example rule for rewriting hardcoded host names:
Output fn="insert-filter" filter="sed-response" sed="s|https://www.oracle.com|https://myoriginserver.oracle.com:8484/myLocalPath|g" type="(text*|application*)"
Example rule for rewriting path references within CSS elements:
Output fn="insert-filter" filter="sed-response" sed="s|url(\"/\\([^\"|^/]\\)|url(\"/myLocalPath/\\1|g" sed="s|url('/\\([^'|^/]\\)|url('/myLocalPath/\\1|g" sed="s|url(/\\([^) |^/]\\)|url(/myLocalPath/\\1|g" type="text/css*"
Note the following when creating host name and path rewriting rules:
You must include the "Content-Type"
attribute values for content types used by the target page in your Oracle Traffic Director configuration file to provide maximum content compatibility when rewriting.
Compressed content is not directly supported by sed; you must configure Oracle Traffic Director to decompress compressed HTML content before applying sed rewriting rules to the content, and recompress it afterwards.
Example rules for decompressing and recompressing HTML content:
Output fn="insert-filter" type="(text*|application*)" filter="http-decompression"
Output fn="insert-filter" type="(text*|application*)" filter="http-compression"
In some cases, you may be able to strip out the "Accept Encoding"
parameter in the request header to prevent the application host from sending compressed data in the first place.
Example rule for stripping out the "Accept Encoding"
header:
AuthTrans fn="set-variable" remove-headers="accept-encoding"
JavaScript code varies widely in complexity and must be examined on a case-by-case basis in order to create clean, compatible rewriting rules.
You can configure Webgate Request Filtering using HTTP request filtering mechanisms.
The Webgate plugin provides the following HTTP request filtering mechanisms:
JavaScript tag injection into incoming (to the user browser) HTML pages
Mock credential substitution in outgoing POST requests
HTTP Basic Authentication credential injection and credential capture
Sanitization of outgoing HTTP requests to remove OAM/ESSO cookies and headers before the request is forwarded to the origin server
The Webgate plugin requires the following Init
directives in magnus.conf
:
To load NSAPI filters and SAFs:
Init fn="load-modules" funcs="OBWebGate_Init,OBWebGate_Authent,OBWebGate_Control,OBWebGate_Err,OBWebGate_Handle401,OBWebGate_Response,EssoBasicAuthInit,EssoBasicAuth,EssoClean" shlib="
webgate.so" obinstalldir="
Webgate_Home_Dir" obinstancedir="
Webgate_Instance_Dir"
Init fn="OBWebGate_Init" obinstalldir="
Webgate_Home_Dir" obinstancedir="
Webgate_Instance_Dir" Mode="PEER"
To enable HTTP Basic Authentication:
Init fn="EssoBasicAuthInit" obinstalldir="
Webgate_Home_Dir" obinstancedir="
Webgate_Instance_Dir" Mode="PEER"
where:
Parameter | Description |
---|---|
|
Full path to the |
|
full path to the target Webgate installation directory. |
|
full path to the Webgate instance directory. |
|
Enable or disable all plugins. |
The JavaScript injection filter provides tag injection into pages incoming into the target user's Web browser.
The following table describes the supported parameters.
Parameter | Description |
---|---|
|
Add to either Enable or disable the JavaScript injection filter. Specifying this directive in |
|
Add to HTML tag to match on for JavaScript injection. |
|
Add to Determines whether to inject the JavaScript tag before or after the |
|
Add to Determines whether the match is case sensitive. |
|
="path", default Add to Passed through to JavaScript as |
|
Add to Passed through to JavaScript as |
|
Add to Partner ID value. Passed through to JavaScript as |
For example, adding the following to obj.conf
AuthTrans fn="set-variable" insert-vars="DYNAMIC-PROXY-ENABLE=on" insert-vars="DYNAMIC-PROXY-MAP-TO=/myTarget" insert-vars="DYNAMIC-PROXY-MAP-FROM=/" insert-vars="DYNAMIC-PROXY-HTTPS=18484" insert-vars="DYNAMIC-PROXY-HTTP=18282" insert-vars="DYNAMIC-PROXY-IGNORE-PATHS=/ignoreMe"
will produce the following result:
Output fn="insert-filter" type="text/*" filter="esso_webproxy" ESSOSearchTag="</title>"
Dynamic Proxy can be enabled and JS Injection Filter Parameters can be inserted into your route as Oracle Traffic Director server variables. To configure the dynamic proxy behavior, the non-null values of the parameters passed to the JavaScript tag.
When dynamic proxy support is enabled (via the DYNAMIC-PROXY-ENABLE
parameter), the following parameters are inserted into your route as Oracle Traffic Director server variables and passed down as JavaScript attributes to configure the dynamic proxy behavior.
Only non-null values will be passed to the JavaScript tag. If either DYNAMIC-PROXY-MAP-FROM
or DYNAMIC-PROXY-MAP-TO
value is not specified, an error ("Dynamic proxy enabled but missing mapTo
/mapFrom
") will be logged. Add these parameters to obj.conf
.
Parameter | Description |
---|---|
|
Enables or disables the dynamic proxy functionality. When disabled, the parameters listed in the remainder of this table are not passed to the JavaScript injection filter. |
|
Destination URI. Default is null (empty string). |
|
Source URI. Default is null (empty string). |
|
HTTPS port number. Default is null (empty string). |
|
HTTP port number. Default is null (empty string). |
|
URIs that should be ignored. Default is null (empty string). |
For example:
<script type='text/javascript' id='MyProxy' src='/myjavascript/myJavaScript.js'essoConsoleLoggingLevel='5' ... mapTo='/myTarget' mapFrom='/' ignorePaths='/ignoreMe' otdHttps='18484' otdHttp='18282'></script></head>
The Mock Credentials filter provides substitution of ESSO mock credentials in the outgoing POST request.
By default, OAM headers are stripped before the request is passed on to the origin server, but they can be forwarded with the pass-oam-headers
parameter.
To enable, add a directive with the parameter to your directive in obj.conf
as follows:
pass-oam-headers="true|false"
, default "false"
This includes the following headers (by default, they are omitted):
OAM_IMPERSONATOR_USER
OAM_REMOTE_USER
OAM_LAST_REAUTHENTICATION_TIME
OAM_IDENTITY_DOMAIN
For example:
Input fn="insert-filter" type="application/x-www-form-urlencoded" filter="esso_webproxy_input" pass-oam-headers="true"
You can configure the HTTP Basic Authentication that provides the ability to capture and inject credentials from and into Web browser basic authentication (modal) dialogs.
Configure HTTP Basic Authentication in the magnus.conf
as follows:
Add the EssoBasicAuthInit
and EssoBasicAuth
functions to the load-modules
Init directive (explained in Configuring the Webgate Request Filtering).
Add a standalone Init directive that loads the ESSOBasicAuthInit
function:
For example:
Init fn="load-modules" funcs="OBWebGate_Init,OBWebGate_Authent,OBWebGate_Control,OBWebGate_Err,OBWebGate_Handle401,OBWebGate_Response,
EssoBasicAuthInit,
EssoBasicAuth
,EssoClean" shlib="
webgate.so" obinstalldir="
Webgate_Home_Dir" obinstancedir="
Webgate_Instance_Dir"
Init fn="
EssoBasicAuthInit
" obinstalldir="
Webgate_Home_Dir" obinstancedir="
Webgate_Instance_Dir" Mode="PEER"
Note:
HTTP Basic Authentication is enabled by default when you install the Access Portal Service. To disable it, remove the EssoBasicAuthInit
and EssoBasicAuth
functions from the load-modules
Init directive and delete the fn="EssoBasicAuthinit"
standalone directive from the magnus.conf
file.
Then, add one or more of the following parameters to obj.conf
for the header injection SAF and the credential capture filter:
Parameter | Description |
---|---|
policy |
Required. Name of the ESSO policy (application template) to use for authentication. |
realm |
Optional. The desired authentication realm of the target website, if more than one realm is in use. |
For example:
NameTrans fn="EssoBasicAuth" policy="BasicAuth1" realm="realm1"
Output fn="insert-filter" filter="esso_output_capture" policy="BasicAuth1" realm="realm1"
The HTTP request sanitizer strips the proxied HTTP request of any cookies and headers added by Oracle Access Manager and the Webgate plugin before the request is forwarded to the origin server.
The sanitizer removes cookies with the following names:
OAM_Partner
OAMAuthnCookie_*
OAMRequestContext*
OAMAuthnHintCookie
OAM_*
ESSO_BAH*
(Basic Authentication Hint, caches policy, realm, and credential GUID)
Request-specific cookie names (for example, containing the server name) are matched using a wildcard, indicated above by the trailing asterisk.
The sanitizer removes the following headers:
OAM_IMPERSONATOR_USER
OAM_REMOTE_USER
OAM_LAST_REAUTHENTICATION_TIME
OAM_IDENTITY_DOMAIN
Note:
The Mock Credentials filter also provides this sanitization, but only while processing HTTP POST requests that contain mock credentials. The Webgate HTTP request sanitizer performs this function unconditionally on all requests.
To enable the sanitizer, add the EssoClean
function to the load-modules
Init directive in the magnus.conf
file. For example:
Init fn="load-modules" funcs="OBWebGate_Init,OBWebGate_Authent,OBWebGate_Control,OBWebGate_Err,OBWebGate_Handle401,OBWebGate_Response,
EssoBasicAuthInit,
EssoBasicAuth,
EssoClean
" shlib="
webgate.so" obinstalldir="
Webgate_Home_Dir" obinstancedir="
Webgate_Instance_Dir"
Then, add the following to the obj.conf
file:
<If not $uri =~ "/oamsso">
NameTrans fn="EssoClean"
</If>
Note:
The HTTP Request Sanitizer is enabled by default when you install the Access Portal Service. To disable it, remove the EssoClean
function from the load-modules
Init directive in the magnus.conf
file, and remove the above code from the obj.conf
file.
The Webgate plugin passes the target credential's GUID value in the proxied URL to the origin server. If the target application does not function properly due to this value being passed, add the following rewrite rule to the Oracle Traffic Director configuration to strip out the GUID value:
<If defined $query and $query =~ "(.*?)(ESSOCredGuid={.*?})(.*)$">
AuthTrans fn="set-variable" set-reqpb="query=$1$3"
</If>