A service account provides a user name and password that proxy services and business services use for outbound authentication or authentication to a local or remote resource, such as an FTP server or a JMS server. For example, if a business service is required to supply a user name and password for transport-level authentication with a Web Service, you create a service account that specifies the user name and password, then you configure the business service to include the service-account credentials in its outbound requests.
The user names and passwords that you enter in service accounts are used for outbound authentication or for providing credentials to local or remote resources. The user names and passwords that you enter in the Security Configuration module of the Oracle Service Bus Administration Console are used for inbound authentication and for authenticating administrative requests. See Section 17.1, "Specifying Service Accounts."
You can use the same service account for multiple business services and proxy services. To specify the user name and password that a service account provides, you can use any of the following techniques:
Static
Requires you to save a user name and password with the service account configuration. The service account encodes this user name and password in the outbound request.
User name and password pass-through
Causes the service account to provide the user name and password that it receives from an incoming client request. For example, if an inbound HTTP BASIC request contains "pat" and "patspassword" as the user name and password, the service account encodes "pat" and "patspassword" in the outbound request.
Because this technique requires that client requests include clear-text user names and passwords, it is applicable only for client requests that use either the HTTP BASIC protocol, a Web Services Security Username Token authentication with a clear-text password, or a custom user name and password token.
Oracle recommends that you use this technique only when Oracle Service Bus and the endpoint belong to the same authentication domain. For example, use this technique when you are routing messages within a single organization and both Oracle Service Bus and the message consumer authenticate against a common LDAP server.
The following restrictions apply to this technique:
It cannot be used in outbound requests that authenticate Oracle Service Bus to a local or remote server or system resource, such as an FTP server or a JMS server.
It cannot be used with the fn-bea:lookupBasicCredentials XQuery function. For more information, see "XQuery Implementation" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Note:
If your proxy is an active WSS intermediary, you can use WS-Security to encrypt a WS-Security Username Token or custom user name/password. In this instance, user name/password pass-through works because the proxy will first decrypt the request and will then have access to the clear-text user name/password.User mapping
Requires you to correlate (map) the user name that is the result of authenticating an inbound request from a client (the local user name) to a user name and password that you specify (the remote user name and password). When the service account receives a request from an authenticated client that has been mapped, it provides the appropriate remote user name and password for the business service or proxy service outbound request.
If the client authenticates at both transport level and message level, the service account maps the message level user name to the remote user name and password.
You can also map an anonymous user name to a remote user name and password.
The following restrictions apply to this technique:
It cannot be used in outbound requests that authenticate Oracle Service Bus to a local or remote server or system resource, such as an FTP server or a JMS server.
It cannot be used with the fn-bea:lookupBasicCredentials XQuery function. For more information, see "XQuery Implementation" in the Oracle Fusion Middleware Administrator's Guide for Oracle Service Bus.
Related Topics
Service accounts and their data participate fully in Oracle Service Bus sessions: you must be in a session to create or modify a service account, and if you discard the session, the service account and its data is also discarded. When you activate a session, Oracle Service Bus saves the user name, password, and other service account data in the user name/password credential mapping provider that is configured for the domain.
To locate Service Accounts:
Do either of the following:
Select Project Explorer to display the Projects View page or the Project/Folder View page. Then navigate through projects and folders to find the service account.
Select Resource Browser > Service Accounts. The Summary of Service Accounts displays the information shown in Table 17-1.
To search for a service account, enter part or all of the account name in the Name field. You can also enter part or all of the account project name and folder in the Path fields. Click Search.
Click View All to remove the search filters and display all service accounts.
Table 17-1 Service Account Information
| Property | Description |
|---|---|
|
Service Account Name |
A unique name for the service account. Click on the name to see the View Service Account Details page. See Section 17.4, "Editing Service Accounts." |
|
Path |
The project name and the name of the folder in which the service account resides. Click on the name to see the project or folder that contains this resource. See Section 4.1.1, "Qualifying Resource Names Using Projects and Folders." |
|
Options |
Contains a Delete icon. If a business service or proxy service has been configured to use a service account, a Deletion Warning icon indicates that you can delete the service account with a warning confirmation. This might result in conflicts due to unresolved references from the service to the deleted service account. See Section 17.5, "Deleting Service Accounts." |
To add a Service Account:
If you have not already done so, click Create to create a new session or click Edit to enter an existing session. See Section 3.1, "Using the Change Center."
Select Project Explorer, then select a project or folder in which to add the service account. The Project/Folder View page is displayed.
From the Create Resource list, select Service Account to display the Create a New Service Account page.
In the Resource Name field, enter a unique name for this service account.
Follow the Section 2.3, "Resource Naming Restrictions" for naming guidance.
In the Resource Description field, enter a description for the service account.
Under Resource Type, do one of the following:
To create a service account that provides the user names and passwords that it receives from incoming client requests, select Pass Through.
To create a service account that provides a user name and password that you save with the service account configuration, select Static.
To create a service account that maps the user name from one or more authenticated clients to user names and passwords that you specify, select Mapping.
Depending on the resource type you selected in the previous step, do one of the following steps described in Table 17-2.
Table 17-2 Resource Type Options
| Selected Resource Type | Complete These Steps |
|---|---|
|
Pass Through |
Click Last. |
|
Static |
|
|
Mapping |
To create a service account that maps the user name from one or more clients to user names and passwords that you specify, do the following:
|
Click Save. The service account is created and saved in the current session.
To end the session and deploy the configuration to the run time, click Activate under Change Center.
To edit a Service Account:
If you have not already done so, click Create to create a new session or click Edit to enter an existing session. See Section 3.1, "Using the Change Center."
Locate the service account, as described in Section 17.2, "Locating Service Accounts."
Click the service account name. The View Service Account Details page displays the information shown in Table 17-3.
Table 17-3 Service Account Details
| Property | Description |
|---|---|
|
Last Modified By |
The user who created this service account or imported it into the configuration. |
|
Last Modified On |
The date and time that the user created this service account or imported it into the configuration. Click the date and time link to view the change history of this resource. See Section 4.23, "View Change History Page." |
|
References |
The number of objects that this service account references. If such references exist, click the numeric link to view a list of the objects. See Section 4.22, "Viewing References to Resources." |
|
Referenced by |
The number of objects that reference this service account. If such references exist, click the numeric link to view a list of the objects. For example, if you selected this service account as the JMS service account in a proxy service with a JMS transport protocol, the proxy service is listed as a reference when you click the link. See Section 4.22, "Viewing References to Resources." |
|
Description |
A description of this service account, if one exists. |
To make a change to the fields, click Edit. See Section 17.3, "Adding Service Accounts" for descriptions of the fields.
You cannot change the Resource Name field.
Click Save to commit the updates in the current session.
To end the session and deploy the configuration to the run time, click Activate under Change Center.
Note:
If the service account that you modified is used to authenticate with a WebLogic JMS server, the JMS server might not recognize your modification for up to 60 seconds. By default, WebLogic Server JMS checks permissions for each destination every 60 seconds. To change this behavior, modify the WebLogic Server startup command so that it sets the following system property to the frequency (in seconds) that you want WebLogic Server JMS to check permissions:weblogic.jms.securityCheckInterval.
A value of 0 (zero) for this property ensures that a permissions check is performed for every send, receive, and getEnumeration action on a JMS resource.
Related Topics
See "Ensuring the Security of Your Production Environment" in Securing a Production Environment.
When you delete a service account, the user name, password, or local-user to remote-user mapping data that the service account contains is also deleted.
If you have not already done so, click Create to create a new session or click Edit to enter an existing session. See Section 3.1, "Using the Change Center."
If any business service or proxy service is configured to use the service account, remove the service account from the business service or proxy service.
See Section 19.5, "Editing Business Service Configurations" or Section 20.5, "Editing Proxy Service Configurations."
Select Resource Browser > Service Accounts to display the Summary of Service Accounts page.
Click the Delete icon in the Options field of the service account you want to delete.
The service account is deleted in the current session. If a business service or proxy service has been configured to use a service account, a Deletion Warning icon indicates that you can delete the service account with a warning confirmation. This might result in conflicts due to unresolved references from the service to the deleted service account.
To end the session and deploy the configuration to the run time, click Activate under Change Center.