Security and Authentication Flows
This topic provides recommendations for safeguarding Oracle’s Siebel OpenIntegration deployment from internal (intranet) and external (Internet) security threats and an overview of configuring security. However, to protect Siebel CRM data, you must secure your Siebel OpenIntegration, Siebel Business Applications and the computing environment in which they run. Refer Siebel Security Guide for detail on protecting Siebel Business Applications. Siebel Open Integration adheres to common security standards to facilitate the integration with the customer
environment. It enables customers to choose a security infrastructure that best suits their specific business needs.
The profile.json is the consolidated file where the Siebel Open Integration users will provide the application and security configuration information. This profile.json will be prepared by referring the profile-template.json explained in the section Configuring Siebel Open Integration, contains the below list of security configuration options 'Security' section in profile.json.
Siebel Open Integration Security Architecture
The components of security architecture include:
- Server security configuration
- User authentication for secure access
- API Authorization for API access control
- Network encryption for data confidentiality
- Encryption for encrypting secrets in configuration files
- CORS Support - Cross-Origin Resource Sharing
Server Security Configuration
The profile.json will have the Server section as depicted below along with the explanations for the key-values. The profile.json enables configuration of Siebel Open Integration. The section “server” provides placeholders for port and keystore/truststore information that will be used by the Siebel Open Integration web server. Provide the port number for the web server to listen to in the field “port” under “server” section. The key and trust stores are configured in the "tls" section. Please ensure that keystore and truststore are available on the paths given. Prepare the profile.json by referring Configuring Siebel Open Integration along with sample profile.json.
"Security": {
"server": {
"port": "Integer value of Webserver port. Example: 8433",
"shutdown-grace-period": "The time interval in ISO 8601 duration format that allows running tasks to finish before the listener shuts down. Example: PT15S",
"tls": {
"trust": {
"keystore": {
"resource": {
"resource-path": "Import Siebel Application Interface (AI) CA certificate into this jks file. Example: siebeltruststore1.jks"
},
"type": "JKS",
"passphrase": "mypassphrase Example: siebel",
"trust-store": true
}
},
"private-key": {
"keystore": {
"resource": {
"resource-path": "This is to keep the service certificate of the generated Microservice and its private key. Example: siebelkeystore1.jks"
},
"type": "JKS",
"passphrase": "privatepassphrase Example: siebel",
"key": {
"alias": "myalias Example: siebel"
}
}
}
}User Authentication for Secure Access
Siebel OpenIntegration only works with Siebel instance configured for SSO based Authentication. Make sure that all relevant Object Managers hosting the resources to be exposed as APIs should be configured for SSO, Siebel REST APIs and the required UI applications exposing the same resources should be configured for SSO in the Application Interface profile and the Siebel Gateway should be configured for SSO in the Gateway Security profile. It supports two types of user authentication.
- OAuth
- Perimeter
Procedure to enable SSO for Siebel instance
1. Setup all relevant Object Managers hosting the resources to be exposed as APIs in SSO
2. Siebel Gateway should be configured for SSO in the Gateway Security profile
OAuth/OpenID Authentication
It is JWT (Java Web Token) based authentication which is default option. You can generate and send OAuth 2.0 based JWT token in the REST request to share authentication/authorization information to access Siebel resources via Siebel Open Integration service. You must install and set up the components, including OAuth components, to suit your own business needs. Out-Of-Box, Siebel Open Integration implementation uses OIDC Provider from Helidon SE for JWT token validation. For an explanation of each property related to OIDC provider refer: https://helidon.io/docs/latest/#/se/security/providers#_oidc_provider
Prepare the profile.json by referring Configuring Siebel Open Integration along with sample profile.json. The profile will have the security section as depicted below along with the explanations for the key-values. The profile.json enables configuration of Siebel Open Integration. The section “security” provides placeholders information will be used by the Siebel Open Integration web server.
Procedure to Configure OAuth authentication for Open Integration
1. Follow the steps under "Procedure to enable SSO Siebel instance". This is a prerequisite for Siebel Open Integration.
2. Apply the below configuration in OpenIntegration to enable OAuth/JWT authentication.
To use OIDC user assertion token:
- Open profile.json
-
- Enable OIDC Provider authentication by setting "enabled": true
- "path": "/data*" => Provide the path of the REST URL in these formats - "/*" or "/data/*" or "/data/Account/*" etc.
- "methods" => Imposes the security for only those HTTP methods under this list
- "authenticate" and "authorize"=> If both set to 'true' needs OIDC/OAuth security user assertion token. If both of them set to 'false' the REST path be accessed via 'Perimeter' security.
- Provide the values for identity-uri, client-id, client-secret, username, password, audience, path and methods with the values as per your deployment. Remaining parameters are constant and keep the same values.
Use the sample configuration for the OIDC security for all Siebel OpenIntegration REST calls with OAuth for all the REST paths.
To use OIDC client credential token:
- Open profile.json
-
- First three steps of user assertion token remains same.
- "authenticate" and "authorize"=> If set to 'true' and 'false' respectively, needs OIDC/OAuth security client credential token.
- Provide the values for identity-uri, client-id, client-secret, audience, path and methods with the values as per your deployment. Remaining parameters are constant and keep the same values.
Note: In a client credentials grant flow, the client ID is sent as a subject. In this case, you must create a Siebel user or employee using the client ID as the USERID, and you must provide access to that user. For additional info, please refer to Security Guide.
"Security": {
"server": {
"port": 8433,
"shutdown-grace-period": "PT15S",
"tls": {
"trust.keystore": {
"resource.resource-path": "siebeltruststore1.jks",
"type": "JKS",
"passphrase": "siebel",
"trust-store": true
},
"private-key.keystore": {
"resource.resource-path": "siebelkeystore1.jks",
"type": "JKS",
"passphrase": "siebel",
"key.alias": "siebel"
}
},
"features": {
"security": {
"paths": [
{
"path": "/data*",
"methods": [
"get",
"post",
"put",
"delete"
],
"authenticate": true
},
{
"path": "/service*",
"methods": [
"get",
"post",
"put",
"delete"
],
"authenticate": true
},
{
"path": "/workflow*",
"methods": [
"get",
"post",
"put",
"delete"
],
"authenticate": true
},
{
"path": "/ui*",
"methods": [
"get",
"post",
"put",
"delete"
],
"authenticate": true
}
]
}
}
},
"security": {
"enabled": true,
"config.require-encryption": false,
"providers": [
{
"oidc": {
"identity-uri": "IDCS URL",
"client-id": "IDCS Client ID",
"client-secret": "IDCS Client Secret",
"audience": "openintv2_",
"server-type": "idcs",
"redirect": false,
"header-use": true
}
}
]
}
}Perimeter Authentication
Perimeter authentication can be used in production only where API Gateway takes care of Authentication and propagates User information via HTTP header with name specified under UserSpec. It Inspects request header specified under UserSpec and extracts value to use as current Subject's Principal.
Procedure to Configure perimeter authentication in Siebel OpenIntegration
- Follow the steps under "Procedure to enable SSO Siebel instance". This is a prerequisite for Siebel OpenIntegration.
- Set the 'UserSpec' value to 'SBL_REMOTE_USER'. The 'UserSpec' must be
configured for corresponding sections of UI(Applications) as well as non-UI
REST(RESTInbound) sections. Error rendering macro 'code': Invalid value specified for parameter
'firstline' "RESTInBound": { "MaxConnections": XX, "RESTAuthenticationProperties": { "TrustToken": "XXX", "AnonUserName": "XXX", "UserSpec": "SBL_REMOTE_USER" }, "ObjectManager": "sccobjmgr_enu" } - To use the 'Perimeter' authentication on any of the selected path, set the
"authenticate": false.
"server": { "features": { "security": { "paths": [ { "path": "/ui", "methods": [ "get", "post", "put", "delete" ], "authenticate": false } ] } } } - Use the sample configuration for the Perimeter security for '/ui' path and
OIDC security for all other Siebel OpenIntegration REST paths.
"Security": { "server": { "port": 8433, "shutdown-grace-period": "PT15S", "tls": { "trust.keystore": { "resource.resource-path": "siebeltruststore1.jks", "type": "JKS", "passphrase": "siebel", "trust-store": true }, "private-key.keystore": { "resource.resource-path": "siebelkeystore1.jks", "type": "JKS", "passphrase": "siebel", "key.alias": "siebel" } }, "features": { "security": { "paths": [ { "path": "/data*", "methods": [ "get", "post", "put", "delete" ], "authenticate": true }, { "path": "/service*", "methods": [ "get", "post", "put", "delete" ], "authenticate": true }, { "path": "/workflow*", "methods": [ "get", "post", "put", "delete" ], "authenticate": true }, { "path": "/ui*", "methods": [ "get", "post", "put", "delete" ], "authenticate": false } ] } } }, "security": { "enabled": true, "config.require-encryption": false, "providers": [ { "oidc": { "identity-uri": "IDCS URL", "client-id": "IDCS Client ID", "client-secret": "IDCS Client Secret", "audience": "openintv2_", "server-type": "idcs", "redirect": false, "header-use": true } } ] } }
API Authorization for API access control
OpenIntegration provides access control for REST APIs using ABAC Authorisation Provider from Helidon SE. Refer https://helidon.io/docs/v4/se/security/providers#_abac_provider for details. ABAC provider has to be used with OIDC provider for API authorisation. Add ABAC provider under security section in the profile.json and update the scope validation rule for a given path under server.features.security.paths section.
Configure the OIDC security as explained below:
- For a given REST path, set the 'authorize' to 'true' to enable the ABAC security for that path.
- Make sure to review and list of methods to be configured under the ABAC security such as 'get', 'post' etc. Note -: If any methods not listed here, will work without any security
- Update the 'scopes' with the value string which has been used during the OAuth security token generation.
- Update the 'abac' section as depicted below.
- In order to enable the 'perimeter', set "authenticate" to 'false' and
'authorize' to 'false'. In the below sample "authenticate" and 'authorize' are
set to 'true' which means OAuth is enabled for the REST
path.
"Security": { "server": { "features": { "security": { "paths": [ { "path": "/*", "methods": [ "get", "post", "put", "delete" ], "authenticate": true, "authorize": true, "abac": { "scopes": [ "XXX" ] } } ] } } }, "security": { "enabled": true, "config.require-encryption": false, "providers": [ { "abac": { "fail-on-unvalidated": true, "fail-if-none-validated": true } }, { "oidc": { "identity-uri": "XXX", "client-id": "XXX", "client-secret": "XXX", "audience": "XXX", "server-type": "idcs", "redirect": false, "header-use": true } } ] } }Use the sample configuration for the ABAC security for Siebel OpenIntegration REST paths.
"Security": { "server": { "port": 8433, "shutdown-grace-period": "PT15S", "tls": { "trust.keystore": { "resource.resource-path": "siebeltruststore1.jks", "type": "JKS", "passphrase": "siebel", "trust-store": true }, "private-key.keystore": { "resource.resource-path": "siebelkeystore1.jks", "type": "JKS", "passphrase": "siebel", "key.alias": "siebel" } }, "features": { "security": { "paths": [ { "path": "/data*", "methods": [ "get", "post", "put", "delete" ], "authenticate": true, "authorize": true, "abac": { "scopes": [ "read" ] } }, { "path": "/service*", "methods": [ "get", "post", "put", "delete" ], "authenticate": true, "authorize": true, "abac": { "scopes": [ "read" ] } }, { "path": "/workflow*", "methods": [ "get", "post", "put", "delete" ], "authenticate": true, "authorize": true, "abac": { "scopes": [ "read" ] } }, { "path": "/ui*", "methods": [ "get", "post", "put", "delete" ], "authenticate": false, "authorize": false, "abac": { "scopes": [ "read" ] } } ] } } }, "security": { "enabled": true, "config.require-encryption": false, "providers": [ { "abac": { "fail-on-unvalidated": true, "fail-if-none-validated": true } }, { "oidc": { "identity-uri": "IDCS URL", "client-id": "IDCS Client ID", "client-secret": "IDCS Client Secret", "audience": "openintv2_", "server-type": "idcs", "redirect": false, "header-use": true } } ] }
Network Encryption for Data Confidentiality
Procedure to configure Siebel Open Integration to accept and send HTTPS request.
- Import Siebel Application Interface (AI) CA certificate into siebeltruststore.jks file referred by “server.keystore. resource.resource-path” for Siebel Open Integration to talk to Application Interface over HTTPS.
- Generate server certificate for the Siebel Open Integration Server and import it into siebelkeystore.jks referred by “private-key.keystore. resource.resource-path”.
- Follow same steps as done to create an SSL certificate for the Siebel Application Interface (AI) today
- Update https port, truststore, keystore file, keystore passphrase and alias in profile.json file under the “server” section
- Place keystore and truststore jks file in openint-deploy folder
Encryption of Sensitive Information in Configuration Files
Siebel Open Integration supports encrypting password or sensitive information as described in profile.json file below.
Procedure to enable encryption
- Set "config.require-encryption" to true under security to enable encryption
- Define master encryption password as the value to the environment variable "SECURE_CONFIG_AES_MASTER_PWD"
- Encrypt the secret using the utility and update it in profile.json file. Refer
below command for encrypting secret.
java -cp "target/libs/*" io.helidon.config.encryption.Main aes masterPassword secretToEncryptmasterPassword - value of the master encryption password to be given as a value to SECURE_CONFIG_AES_MASTER_PWD env variable.
secretToEncrypt - secret to be encrypted.
Refer: https://helidon.io/docs/v4/mp/security/configuration-secrets#_encrypting_values_aes for details
"Security": { "server": { "port": XXXX, "shutdown-grace-period": "PT15S", "tls": { "trust.keystore": { "resource.resource-path": "siebeltruststore1.jks", "type": "JKS", "passphrase": "<encrypted value>", "trust-store": true }, "private-key.keystore": { "resource.resource-path": "siebelkeystore1.jks", "type": "JKS", "passphrase": "<encrypted value>", "key.alias": "<encrypted value>" } } "security": { "enabled": true, "config.require-encryption": true, "providers": [ { "oidc": { "identity-uri": "********", "client-id": "********", "client-secret": "<encrypted value>", "audience": "********", "server-type": "idcs", "redirect": false, "header-use": true } } ] }
Encryption Steps with Sample Values
-
Set "config.require-encryption": true
-
Set the environment variable SECURE_CONFIG_AES_MASTER_PWD with master password value as "openint" for example.
export
SECURE_CONFIG_AES_MASTER_PWD=openint -
Generate the encrypted passphrase value by using the below command for the passphrase "siebel"
java -cp "target/libs/*" io.helidon.config.encryption.Main aes openint siebelGenerated encrypted string :
${GCM=aUP6KWK2mC4kfKrVMPfV5RVPRk5l65rGWy7ocyyDyYl55WnwgW4vozlVopsZyvTWL/Q=} -
Generate the encrypted client-secret value by using the below command for the client-secret "441a09a3-21bd-4d26-bcc7-ce681cca93f6"
java -cp "target/libs/*" io.helidon.config.encryption.Main aes openint 441a09a3-21bd-4d26-bcc7-ce681cca93f6Generated encrypted string :
${GCM=3p9/VJX6Emls9MWTE8a7u41vf6Nb/VwGD7SYnoytykWwCv81t4Sg1zQiOg6c2mfBw3E9if27Ju8XW4h/PN8fyacTUccDHIzmHwCksCrpwyE=} - Update the above generated encrypted strings in the profile.json as below :
"Security": { "server": { "port": XXXX, "shutdown-grace-period": "PT15S", "tls": { "trust.keystore": { "resource.resource-path": "siebeltruststore1.jks", "type": "JKS", "passphrase": "${GCM=aUP6KWK2mC4kfKrVMPfV5RVPRk5l65rGWy7ocyyDyYl55WnwgW4vozlVopsZyvTWL/Q=}", "trust-store": true }, "private-key.keystore": { "resource.resource-path": "siebelkeystore1.jks", "type": "JKS", "passphrase": "${GCM=aUP6KWK2mC4kfKrVMPfV5RVPRk5l65rGWy7ocyyDyYl55WnwgW4vozlVopsZyvTWL/Q=}", "key.alias": "${GCM=aUP6KWK2mC4kfKrVMPfV5RVPRk5l65rGWy7ocyyDyYl55WnwgW4vozlVopsZyvTWL/Q=}" } } "security": { "enabled": true, "config.require-encryption": true, "providers": [ { "oidc": { "identity-uri": "********", "client-id": "********", "client-secret": "${GCM=3p9/VJX6Emls9MWTE8a7u41vf6Nb/VwGD7SYnoytykWwCv81t4Sg1zQiOg6c2mfBw3E9if27Ju8XW4h/PN8fyacTUccDHIzmHwCksCrpwyE=}", "audience": "********", "server-type": "idcs", "redirect": false, "header-use": true } } ] } -
Bounce Siebel Open Integration, if already running
Cross-Origin Resource Sharing (CORS)
Siebel Open Integration provides cross-origin resource sharing (CORS) support to control if and how REST resources served by their applications can be shared across origins. You can use it to add CORS behavior to the services you develop. Out-Of-Box, Open Int provides CORS support for all the origins and methods. You can restrict it by adding rules in config file. It is recommended that before you revise your application to add CORS support, you need to decide what type of cross-origin sharing you want to allow for each resource your application exposes. For example, suppose for a given resource you want to allow unrestricted sharing for GET and POST requests (what CORS refers to as "simple" requests), but permit PUT and DELETE requests only from the two origins test1.com and test2.com. Your application would implement three types of CORS sharing: more relaxed for the simple requests, stricter for others and overrides to override stricter rule. CORS rule get evaluated in the order simple, stricter (restrictive-cors) and overrides (cors). Add CORS related configurations after security section in configuration file.
simple - no configuration required. It allows all origins and methods.
stricter - Related configurations go under restrictive-cors section.
overrides - Related configurations go under cors section.
This restrictive rule allows sharing PUT and DELETE with test1.com and test2.com
"restrictive-cors": {
"allow-origins": [
"https://foo.com",
"https://there.com"
],
"allow-methods": [
"GET",
"DELETE"
]
}Any overrides on top of restrictive should be added under cors section. This override allows sharing resource with test3.com in addition to test1.com and test2.com.
"restrictive-cors": {
"allow-origins": [
"https://foo.com",
"https://there.com"
],
"allow-methods": [
"GET",
"DELETE"
]
},
"cors": {
"paths": [
{
"path-pattern": [
"/"
],
"allow-origins": [
"https://foo.com",
"https://there.com",
"https://test3.com"
],
"allow-methods": [
"GET",
"DELETE"
]
}
]
}