Managing Security and Authentication

Siebel Open Integration helps you expose Siebel CRM resources as REST APIs while aligning with common security standards. Managing security and authentication in Siebel Open Integration involves configuring design-time artifacts and runtime components that control how the application is built, secured, and executed.

To secure the deployment, you must configure the following:

Siebel Open Integration security components. For more information, see Configuring Security for Siebel Open Integration.
Siebel Business Applications. For more information on securing Siebel Business Applications, refer to the Siebel Security Guide.
The underlying computing environment.

The profile.json file is the central configuration file for application and security settings. It is created based on profile-template.json. For more information, see Configuring Siebel Open Integration.

Configuring Security for Siebel Open Integration

To configure security for Siebel Open Integration, you must:

Configure server security. For more information see, Configuring Server Security.
Configure user authentication for secure access. For more information, see Configuring User Authentication.
Configure API authorization for API access control. For more information, see Configuring API Authorization.
Configure network encryption for data confidentiality. For more information, seeConfiguring Network Encryption.
Encrypting sensitive information such as secrets, in configuration files. For more information, seeEncrypting Configuration Files.
Configure support for Cross-Origin Resource Sharing (CORS). For more information, see Configuring support for CORS.

Configuring Server Security

You can configure server security in the profile.json file using the client and server sections:

The server section defines TLS settings for inbound connections. It specifies the truststore and server keystore used to validate certificates and present the server identity.
The client section defines TLS settings for outbound connections. It defines the client keystore used by Siebel Open Integration when it establishes secure outbound (SSL/TLS) connections to external systems.

Note: You must ensure that the keystore and truststore JKS files are available in the configured path.

Note: If you are using a single certificate for both server and client authentication, you can continue to use it until it expires. In this case, configure both the client and server sections in profile.json to reference the same keystore that contains this certificate. After you renew the certificate, update the client and server sections with the renewed certificate information.

For more information about the sections and parameters in the profile.json file, see Configuring profile.json.

Configuring User Authentication

Siebel Open Integration requires SSO based authentication for secure access. It only works with Siebel instances that are configured for SSO. You must ensure that the following components are configured for SSO:

Object Managers that host resources exposed as APIs.
Siebel REST APIs.
User interface (UI) applications in the Application Interface profile.
Siebel Gateway in the Gateway Security profile.

To enable SSO for a Siebel instance:

Configure all Object Managers that host resources exposed as APIs to use SSO.
Configure the Siebel Gateway to use SSO in the Gateway Security profile.

Siebel Open Integration supports the following user authentication methods:

OAuth. For steps to enable OAuth authentication, see Enabling OAuth Authentication.
Perimeter authentication. For steps to enable perimeter authentication, see Configuring Perimeter Authentication.

Enabling OAuth Authentication

OAuth authentication in Siebel Open Integration uses JSON Web Token (JWT). This is the default authentication method.

You can generate an OAuth 2.0 based JWT token and include it in REST requests. The token carries authentication and authorization information required to access Siebel resources. Siebel Open Integration uses an OpenID Connect (OIDC) provider to validate JWT tokens. By default, it uses the Helidon SE OIDC provider. For details about OIDC provider properties, see the Implemented Security Providers section in the Helidon online documentation.

The profile.json file defines the security configuration for the Siebel Open Integration server. You must update this file to match your environment by configuring the required authentication mechanisms and security settings, as described in the Configuring profile.json section.

To configure OAuth authentication for Siebel Open Integration:

Enable SSO for Siebel instance as discussed above.
Enable OAuth or JWT authentication through OIDC user assertion token or client credentials in profile.json, as follows:
1. In the Openint > server > security section, set the enabled parameter to true.
2. In the Openint > server > features > security section, configure REST paths:
  1. Set the path parameter to REST path. For example, /*, /data/*, /service/*.
  2. Specify methods such as get, post, put, and delete.
  3. Set the authenticate and authorizeparameters:
    - Set authenticate to true and authorize to true for user assertion token flow.
    - Set authenticate to true and authorize to false for client credentials flow.
3. In theOpenint > server > security > providers -> oidc section,configure the following parameters as per your deployment:
  - identity-uri
  - client-id
  - client-secret
  - audience
4. Keep all other parameters unchanged unless your deployment requires updates.

Note: Use the sample configuration to apply OIDC security to all Siebel Open Integration REST paths. This ensures that OAuth authentication is enforced consistently across all endpoints.

Note:

In a client credentials grant flow, the client ID is used as the subject. You must create a Siebel user or employee with the client ID as the USERID and assign the required access permissions to that user. For more information, refer the Siebel Security Guide.

For a sample profile.json configuration, see Configuring profile.json.

Configuring Perimeter Authentication

You can use perimeter authentication in production only when an API Gateway performs authentication and forwards the authenticated user identity in an HTTP header. Siebel Open Integration reads the header specified in UserSpec and uses it as the current subject’s principal.

To configure perimeter authentication in Siebel Open Integration:

Enable SSO for the Siebel instance.
Set UserSpec to SBL_REMOTE_USER. You must configure UserSpec for both UI (Applications) and non-UI REST (RESTInbound) sections.
Set the authenticate parameter to false for any Open Integration REST path that should use perimeter authentication.

Use perimeter authentication (set authenticate to false) for /ui path while keeping OIDC enabled (set authenticate to true) for the other REST paths.

{
          "path": "/ui*",
           "methods": [
              "get",
              "post",
              "put",
              "delete"
            ],
           "authenticate": false
       }

For a sample profile.json configuration, see Configuring profile.json.

Configuring API Authorization

Siebel Open Integration provides access control for REST APIs using the ABAC authorization provider from Helidon SE. The ABAC provider works together with the OIDC provider to enforce authorization based on token scopes.

For more information about ABAC provider configuration, refer ABAC Provider section in the online Helidon documentation.

The ABAC provider must be used together with the OIDC provider to enable API authorization.You must add the ABAC provider under the security.providers section in profile.json and define scope validation rules for each REST path under the server.features.security.paths section.

To configure the OIDC security with OAuth under each REST path:

Set authorize to true to enable ABAC authorization.
Note: To configure perimeter access, if required, set authenticate to false and authorize to false for paths that use perimeter authentication.
Specify HTTP methods (get, post, put, and delete). Only the listed methods are secured. Methods not listed are not protected.
Set "scopes" to match the values used during OAuth token generation.

Add the abac section as follows:

"paths": [
{
"path": "/data*",
"methods": ["get", "post", "put", "delete"],
"authenticate": true,
"authorize": true,
"abac": {
"scopes": ["read"]
}
}
	]

Sample configuration for the ABAC security for Siebel Open Integration REST paths.

{
"Openint": {	
"server": {
"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
}
}
]
}
}
}

Configuring Network Encryption

Siebel Open Integration supports HTTPS to ensure data confidentiality during communication with external systems.

To configure Siebel Open Integration to accept and send HTTPS request:

Import the Siebel Application Interface CA certificate into the truststore:
1. Add the certificate to siebeltruststore.jks.
2. Reference this file in server.keystore.resource.resource-path.
Generate a server certificate for Siebel Open Integration:
1. Import the certificate into siebelkeystore.jks.
2. Reference this file in private-key.keystore.resource.resource-path.
Create an SSL certificate for the Siebel Application Interface. For the steps to create an SSL certificate, refer the About Certificates and Key Files Used for TLS Authentication section in Siebel Security Guide.
Copy the keystore and truststore JKS files in the openint-deploy directory.
Update the profile.json file to configure the following under the server section:
1. Configure HTTPS port.
2. Configure truststore and keystore paths.
3. Provide keystore passphrase and key alias.

Encrypting Configuration Files

Siebel Open Integration supports encryption of sensitive values such as passwords in the profile.json file.

To enable encryption:

Set environment variable SECURE_CONFIG_AES_MASTER_PWD to define the master encryption password. For example:
```
export SECURE_CONFIG_AES_MASTER_PWD=openint
```

Use the Helidon encryption utility to encrypt sensitive values:

java -cp "target/libs/*" io.helidon.config.encryption.Main aes masterPassword secretToEncrypt

In the above example:

<masterPassword> is the value of SECURE_CONFIG_AES_MASTER_PWD.
<secretToEncrypt> is the value to encrypt.

For example:

java -cp "target/libs/*" io.helidon.config.encryption.Main aes openint siebel

Generated encrypted string is

${GCM=aUP6KWK2mC4kfKrVMPfV5RVPRk5l65rGWy7ocyyDyYl55WnwgW4vozlVopsZyvTWL/Q=}

Generate the encrypted client-secret value for the client-secret "441a09a3-21bd-4d26-bcc7-ce681cca93f6"

java -cp "target/libs/*" io.helidon.config.encryption.Main aes openint 441a09a3-21bd-4d26-bcc7-ce681cca93f6

Generated encrypted string is

${GCM=3p9/VJX6Emls9MWTE8a7u41vf6Nb/ VwGD7SYnoytykWwCv81t4Sg1zQiOg6c2mfBw3E9if27Ju8XW4h/PN8fyacTUccDHIzmHwCksCrpwyE=}

Update profile.json as follows:

Set config.require-encryption to true under the security section.

Replace plain text values in profile.json with encrypted values. For example:

"Openint": {
"server": {
"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
}
}
]
}
}
}

Restart Siebel Open Integration for changes to take effect.

For more information on encryption, refer the Encrypting values section in the Helidon online documentation.

Configuring Support for CORS

Siebel Open Integration supports Cross-Origin Resource Sharing (CORS) to control how REST resources are accessed from different origins.

By default, CORS is enabled for all origins and HTTP methods. To restrict access, you can define CORS rules in the profile.json configuration file. Add the CORSconfigurations after the security section.

Before configuring CORS, determine the required access level for each resource. For example, you might allow unrestricted access for simple requests (GET, POST) and restrict other methods (PUT, DELETE) to specific origins (for example, test1.com and test2.com).

Your application can implement three CORS behaviors:

Simple
- No configuration required. A relaxed policy for simple requests.
- Allows all origins and HTTP methods.
Restrictive (restrictive-cors)
- Use the restrictive-cors section to define global restrictions (a stricter policy for certain requests).
- Sample restrictive-cors configuration in profile.json:
```
"restrictive-cors": { 
	"allow-origins": [ 
	"https://foo.com", 
	"https://there.com"
	],
	"allow-methods": [ 
	"GET",
	"DELETE"
	]
	}
```
  This configuration allows only the specified origins to access the listed HTTP methods.

Overrides (cors)

This configuration allows only the specified origins to access the listed HTTP methods.

Sample cors configuration in profile.json:

{
	"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"
]
}
]
}
}

This override allows access for test3.com in addition to test1.com and test2.com.

CORS rules are evaluated in the following order:

Simple (default behavior)
Restrictive (restrictive-cors)
Overrides (cors)