OAuth2 for PeopleSoft REST Authorization

OAuth 2.0 is a protocol that allows a user to grant limited access to their resources on one site to another site without having to expose their credentials. It is commonly used as a way for web services to authenticate and authorize users. It can be very confusing to set up and use across vendors as the terminology is dense and different vendors can have slightly different implementations and naming. I find the same thing with SAML.

PeopleSoft has added support for OAuth 2.0 in PeopleTools 8.59. A few different IDPs (Identity Providers) are supported out of the box, including:

• Azure
• OKTA (covered in this guide)
• IDCS
• Ping

OAuth 2.0 is a complex topic, and I will not be able to cover all the details in this guide. I will focus on how to set up OAuth in PeopleSoft and how to use it in your REST services.

• This guide will cover:

  • Setting up OAuth in PeopleSoft with OKTA
  • We will be using the “Authorization Code” flow. This is when a web application that you created redirects a user to the IDP to authenticate and authorize the application. The IDP then sends a code back to the application which is then exchanged for an access token. If you don’t understand this I urge you to go watch some YouTube videos on OAuth 2.0 or go study the https://www.oauth.com website.
  • Using OAuth in your REST services when PeopleSoft is acting as the Server hosting the REST service. (Resource Server)
  • This guide test the functionality using PeopleTools 8.61.01 and OKTA as the IDP.
  • Debating the pro and cons of using OAuth 2.0. There are some specific use cases where OAuth 2.0 is a good fit and some where it is not. I will not cover this in this guide.

• What this guide will NOT cover:

  • Understanding OAuth 2.0 in detail. I recommend reading the OAuth 2.0 RFC if you want to understand the protocol in detail or the various YouTube videos on the topic.
  • How a “Web Application” gets the access token from the IDP. This is a complex topic and is not covered here. There are many flows and use cases.

• Warnings and Caveats:

  • There is almost zero documentation from Oracle on how to set this up. The only way I figured this out was by a bunch of testing and experimentation. The mapping of the JWT claims to an OPRID is the most important part of the setup and I to open a Support Case to get this information as it was not in the documentation or support notes. (Oracle Scores an F on most PeopleSoft documentation)
  • The PeopleSoft oAuth2 support is new and there are some limitations.
    • There is no way to have custom logic to map a JWT claim to an OPRID using custom code. See the mapping section.
  • If you enable oAuth2 on a service operation Req. Verification you can no longer use Basic Authentication or PS Token. You do NOT need to explicitly set the service operation to oAuth2 for the service to accept a JWT token. You can leave it as NONE and the service will still accept the JWT token.
  • The JWT token validation happens on the Integration Broker Web Server.

• Random Facts

  • It looks like you cannot have two different IDPs setup in PeopleSoft. I tried to set up two different IDPs and it did not work. I think you can only have one IDP setup at a time.
    • These values from the integrationGateway.properties file are used to determine the IDP are singular.
      • ig.AuthorizationServer
      • ig.JSONWebKey

OAuth2 JWT Claims to OPRID Mapping

First let’s talk about the mapping of the JWT claims to an OPRID. This mapping is important because the JWT token will have a claim that will be used to map to a valid OPRID in PeopleSoft. This is how PeopleSoft will know who the user is that is making the request and then basically authenticate the API call as a valid user. No code in PeopleSoft can run without some valid user context.

When using openid connect, the JWT token will have two important claims that are used to map to a valid OPRID.

• The sub claim has to contain a value that maps to a valid OPRID. This is case-sensitive, and the IDP must know this value.
• The email claim has to contain the email address for the OPRID. This email address has to match the email address on the PSUSEREMAIL table for the OPRID in the sub claim.
  • This is case-sensitive and the IDP must know this value and you must populate the email address in the PSUSEREMAIL table which is not always common across the clients I have worked with. Additionally, in non-production environments the email address is often scrambled so non-production systems don’t send out emails.

Make sure that your IDP and PeopleSoft can send and receive these claims before you proceed.

What I would like PeopleTools to be able to do is to have a custom PeopleCode function that can map a claim to an OPRID. This could also be accomplished with some sort of configuration file on the server that could map a claim to an OPRID. I find the current setup to be very limiting and not very flexible. It looks more like an MVP (Minimum Viable Product) than a full-featured solution. This is coming from working on many clients where the OPRID landscape has evolved over time and is not always clean and consistent.

Configuration of Basic REST Web Service

First, we need to create a basic REST service in PeopleSoft. We will create a simple “Metadata” service that will return the metadata about the user running the service and information about the database. We will first test it with basic Authentication and then switch to OAuth.

Here is a screenshot of the service operation setup:

• This is GET Service
• We have authentication set to NONE for now. This does NOT mean that the service is not secure. A user still must authenticate to the PeopleSoft web server to get the service. (See the Properly Securing the ANONYMOUS IB Node for more information.)
• There are NOT any required parameters for this service.
• It returns JSON.

Here is the entire PeopleSoft Handler Code.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37

import PS_PT:Integration:IRequestHandler;


class MetaDataHandler implements PS_PT:Integration:IRequestHandler
   method MetaDataHandler();
   method OnRequest(&msgRequest As Message) Returns Message;
   
end-class;



method MetaDataHandler
   /* Nothing here for now */
end-method;

method OnRequest
   /+ &msgRequest as Message +/
   /+ Returns Message +/
   /+ Extends/implements PS_PT:Integration:IRequestHandler.OnRequest +/
   
   Local Message &msgResponse;
   &msgResponse = CreateMessage(@("Operation." | &msgRequest.OperationName), %IntBroker_Response);

   Local JsonObject &jResponse = CreateJsonObject();
   
   &jResponse.AddProperty("currentUser", %OperatorId);
   &jResponse.AddProperty("dbname", %DbName);
   &jResponse.AddProperty("toolsRelease", %ToolsRelease);
   &jResponse.AddProperty("psftTransactionId", &msgRequest.IBInfo.TransactionID);
   &jResponse.AddProperty("responseDTTM", DateTimeToHTTP(%Datetime));
   &jResponse.AddProperty("dbType", %DbType);
   &jResponse.AddProperty("serverTimeZone", %ServerTimeZone);
   
   Local boolean &b = &msgResponse.SetContentString(&jResponse.ToString());
   
   Return &msgResponse;   
end-method;

• We create a standard PeopleSoft OPRID and password and create a basic authentication header. If this is new to you then please read the REST Security Section for more information.

• Now we use an API tester like CURL to test the service.

• Here is the full HTTP request and response.

GET https://34.16.144.215:8000/PSIGW/RESTListeningConnector/PSFT_CS/CHG_METADATA.v1/ HTTP/1.1
accept-encoding: gzip, deflate, br
accept: */*
authorization: Basic Q0hHX0FQSV9URVNUOkFVTEQ2YXJlbmEzYWNhcHVsY28=

HTTP/1.1 200 OK
connection: close
content-encoding: gzip
content-length: 214
content-type: application/json; encoding=UTF-8
date: Fri, 13 Dec 2024 17:07:13 GMT
x-oracle-dms-ecid: 5c8484a0-32b4-4ec3-b376-56dab4e1f77d-000000b1
x-oracle-dms-rid: 0

{
  "currentUser": "CHG_API_TEST",
  "dbname": "CS92DEV",
  "toolsRelease": "8.61.03",
  "psftTransactionId": "b2ac0244-b974-11ef-a5b0-4552a628bb05",
  "responseDTTM": "Sat, 14 Dec 2024 01:07:13 GMT",
  "dbType": "ORACLE",
  "serverTimeZone": "PST"
}

Setting up OAuth2 - OKTA

For PeopleSoft accept JWT tokens from an IDP like OKTA, we need to establish a trust between the two systems. This involves “registering” PeopleSoft as a “client” in OKTA and then configuring PeopleSoft to accept the JWT tokens from OKTA.

What we are going for here is to get a JWT token created that has information about a valid PeopleSoft user that can be used to execute the REST service.

• In my testing, I created a new “Authorization Server” in OKTA which allows you to control and remap the JWT Claims.

  • This is done by logging into your OKTA account and selecting the “Security” tab and then clicking on the “API” tab.
  • I am not going to cover all the detail here as it is specific to OKTA. You can read the OKTA documentation for more information.

• Some Important settings in OKTA on the Authorization Server:

  • The “scopes” on the Authorization Server need to have the “openid” scope
  • The “claims” needs to have the “sub” and “email” claims. In my case, I setup:
    • sub maps to the OPRID using appuser.userName. This is OKTA’s way of saying “username” for the “application”.
      • OKTA has to send the sub claim with the value of the OPRID. Otherwise, PeopleSoft will not be able to map the JWT token to a valid OPRID.
    • email maps to the email for the OPRID using user.email. This email address has to match the email address on the PSUSEREMAIL table for the OPRID in the sub claim.

• The Authorization Server setup will give you a MetaData URI which you will need to configure in PeopleSoft. In my case that is:

  • https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/.well-known/oauth-authorization-server
  • You can do an HTTP GET on that URL to get the metadata about the Authorization Server. This is important for PeopleSoft to validate the JWT token. The JSON returned looks like the following:
    • A few pieces you need to extract from that for the PeopleSoft Server are:
      • issuer - Used in the “Create OAuth2 Service Apps” page in PeopleSoft
        • warning OKTA may NOT send this exact value in the JWT token. There are some settings where this can be different. I suggest that you decode the JWT token and see what the iss claim is set to.
      • jwks_uri - Used in integrationGateway.properties
      • authorization_endpoint - Used in the “Create OAuth2 Service Apps” page in PeopleSoft. Your web application will use this to redirect the user to OKTA to authenticate and authorize the application.
        • I don’t think PeopleSoft uses this and I think only the issuer is used to validate the JWT token. (I need to validate this)
      • token_endpoint - Used in the “Create OAuth2 Service Apps” page in PeopleSoft. You web application will use this to get the access token from OKTA.
        • I don’t think PeopleSoft uses this and I think only the issuer is used to validate the JWT token. (I need to validate this)

{
  "issuer": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8",
  "authorization_endpoint": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/v1/authorize",
  "token_endpoint": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/v1/token",
  "registration_endpoint": "https://dev-126519.oktapreview.com/oauth2/v1/clients",
  "jwks_uri": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/v1/keys",
  "response_types_supported": [
    "code",
    "token",
    "id_token",
    "code id_token",
    "code token",
    "id_token token",
    "code id_token token"
  ],
  "response_modes_supported": [
    "query",
    "fragment",
    "form_post",
    "okta_post_message"
  ],
  "grant_types_supported": [
    "authorization_code",
    "implicit",
    "refresh_token",
    "password",
    "client_credentials",
    "urn:ietf:params:oauth:grant-type:device_code"
  ],
  "subject_types_supported": [
    "public"
  ],
  "scopes_supported": [
    "openid",
    "profile",
    "email",
    "address",
    "phone",
    "offline_access",
    "device_sso"
  ],
  "token_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "client_secret_jwt",
    "private_key_jwt",
    "none"
  ],
  "claims_supported": [
    "ver",
    "jti",
    "iss",
    "aud",
    "iat",
    "exp",
    "cid",
    "uid",
    "scp",
    "sub"
  ],
  "code_challenge_methods_supported": [
    "S256"
  ],
  "introspection_endpoint": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/v1/introspect",
  "introspection_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "client_secret_jwt",
    "private_key_jwt",
    "none"
  ],
  "revocation_endpoint": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/v1/revoke",
  "revocation_endpoint_auth_methods_supported": [
    "client_secret_basic",
    "client_secret_post",
    "client_secret_jwt",
    "private_key_jwt",
    "none"
  ],
  "end_session_endpoint": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/v1/logout",
  "request_parameter_supported": true,
  "request_object_signing_alg_values_supported": [
    "HS256",
    "HS384",
    "HS512",
    "RS256",
    "RS384",
    "RS512",
    "ES256",
    "ES384",
    "ES512"
  ],
  "device_authorization_endpoint": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/v1/device/authorize",
  "dpop_signing_alg_values_supported": [
    "RS256",
    "RS384",
    "RS512",
    "ES256",
    "ES384",
    "ES512"
  ]
}

• Next we need to create an “Application” in OKTA. This is done by logging into your OKTA account and selecting the “Applications” tab and then clicking on the “Add Application” button.
  • I chose the OIDC - OpenID Connect option and did a “Web Application” type. Your OKTA admin will know what to do here.
  • This will give you a “Client ID” and a “Client Secret” that your application developers will use to get the access token from OKTA.
    • The “Client ID” and “Client Secret” are NOT used in PeopleSoft. This is used by the code that needs to access the PeopleSoft web server and then submit a Bearer token in the HTTP header to PeopleSoft.

Setting Up PeopleSoft - OKTA

There are a few steps to set up PeopleSoft to accept JWT tokens.

Remember that for this article we are limiting the setup to have a protected PeopleSoft web service that is only accessible by a valid JWT token from OKTA. So the setup here is limited to the information that PeopleSoft needs to validate and trust the JWT token and map to a valid OPRID.

First we need to set up PeopleSoft using a page to “register” OKTA as an IDP.

• PeopleTools → Security → OAuth2 Administration → Create OAuth 2 Service Apps
  • Add a new value with the information pull from the OKTA Authorization Server metadata URI that we got earlier.
  • You have to be extremely careful with the values you put in here. If you make a mistake the JWT cannot be validated.
    • Note the page has a bug when saving that the client “secret” is a required field. You may have to select the “client and resource” and input any fake secret to get the page to save. This is a bug in PeopleTools 8.61.03. That secret is NOT used for the flow we are setup up.

Next we need to change the integration broker web server integrationGateway.properties file to point to the OKTA JWKS URI. This is the URL that OKTA uses to publish the public keys that are used to validate the JWT token. If you have more than one web server make sure you are making this change on the web service that is hosting serving the REST service.

The ig.JSONWebKey value is the URL that OKTA uses to publish the public keys that are used to validate the JWT token. For OKTA, this is in the metadata URI that we got earlier in the jwks_uri field.

ig.AuthorizationServer=OKTA
ig.JSONWebKey=https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8/v1/keys

You can only have one IDP setup in PeopleSoft. I tried to set up two different IDPs and it did not work. I think you can only have one IDP setup at a time.

While testing this, I highly recommend that you also turn on the highest logging level for the integration broker. This will give you important troubleshooting messages that will show in the msgLog.html and errorLog.html files on the Integration Broker web server.

That is done by setting the following property.

ig.log.level=5

After those changes bounce the integration broker web service.

Testing the OAuth2 Service

First let’s see what happens when we try to submit a bear token when the service operation is still set to NONE for authentication.

I will not explain how to get the Bear token because your application developers will have to do that. This is a complex topic and is not covered here. We just assume you have an application that can generate a valid JWT token from OKTA and submit it in the HTTP header as a Bearer.

Let’s look at the HTTP request and response.

GET http://34.16.144.215:8000/PSIGW/RESTListeningConnector/PSFT_CS/CHG_METADATA.v1/ HTTP/1.1
accept-encoding: gzip, deflate, br
accept: application/json
authorization: Bearer eyJraWQiOiJKRnF1MExEOWIxWEJLSV9ZLS1MRlpiQmN6ZFNiZGdMSURxVzBoSkhaWWtRIiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULlhTNDY4ZlZ0a2RGTmNQdWxqMWJwNl9SUEdCWjkxLUxqcXJrd1BlT2trdTQiLCJpc3MiOiJodHRwczovL2Rldi0xMjY1MTkub2t0YXByZXZpZXcuY29tL29hdXRoMi9hdXMyOXp3ZTh3cThTVmw4ODBoOCIsImF1ZCI6ImNoZy10ZXN0IiwiaWF0IjoxNzM0MTIyODU5LCJleHAiOjE3MzQxMjY0NTksImNpZCI6IjBvYTI5eHBzcGxua2xTS0F5MGg4IiwidWlkIjoiMDB1NXJxaDR0bEkya3ZvczMwaDciLCJzY3AiOlsib3BlbmlkIl0sImF1dGhfdGltZSI6MTczNDEwOTc2Niwic3ViIjoiQ0hSSVNNQUxFSyIsImVtYWlsIjoiY2hyaXMubWFsZWtAY2VkYXJoaWxsc2dyb3VwLmNvbSJ9.R9yzqIijo4hD8fooiOMjT_ZVUYDOXLDA_05gfTErcU8EJYHQyG3Npkj-Tg4XLE3DJvMnJohPsKFdrj65nWgKTMyxGQTawSgKJzuu4sMWGbt87L9yf-VabvrUMxNLmSpTNygXSemj8Gy5zxR8qrdHs5pRMHZfd4PQy-dFzV9r7RFG2ilBkJW6BPLc1-YuySSwYG1aAFvin1bluTpJLaTPn5i08btj08SGfpzAYP_gRQLlmj-puF3reSSxYB5hOZ08ZA2SoNhCLyBJXftGjz27wvpsNw0iM1CIKziNmO1JbT-okN5oA2AXPsEvSQwfUZG7ZUNE6Uy8E5s9B65QrwGHIA
user-agent: httpyac

HTTP/1.1 200 OK
connection: close
content-encoding: gzip
content-length: 212
content-type: application/json; encoding=UTF-8
date: Fri, 13 Dec 2024 21:05:21 GMT
x-oracle-dms-ecid: 5c8484a0-32b4-4ec3-b376-56dab4e1f77d-000001b4
x-oracle-dms-rid: 0

{
  "currentUser": "CHRISMALEK",
  "dbname": "CS92DEV",
  "toolsRelease": "8.61.03",
  "psftTransactionId": "f6ec619a-b995-11ef-a5b0-4552a628bb05",
  "responseDTTM": "Sat, 14 Dec 2024 05:05:20 GMT",
  "dbType": "ORACLE",
  "serverTimeZone": "PST"
}

What did we see? The curretUser is set to CHRISMALEK which is the OPRID that the JWT token is mapped to. Where did that come from? Let’s look at the Bearer token and see what it is.

If you take the Bearer token and decode it using something like jwt.io you will see the following:

The JWT Header:

{
  "kid": "JFqu0LD9b1XBKI_Y--LFZbBczdSbdgLIDqW0hJHZYkQ",
  "alg": "RS256"
}

The JWT Payload:

{
  "ver": 1,
  "jti": "AT.XS468fVtkdFNcPulj1bp6_RPGBZ91-LjqrkwPeOkku4",
  "iss": "https://dev-126519.oktapreview.com/oauth2/aus29zwe8wq8SVl880h8",
  "aud": "chg-test",
  "iat": 1734122859,
  "exp": 1734126459,
  "cid": "0oa29xpsplnklSKAy0h8",
  "uid": "00u5rqh4tlI2kvos30h7",
  "scp": [
    "openid"
  ],
  "auth_time": 1734109766,
  "sub": "CHRISMALEK",
  "email": "chris.malek@cedarhillsgroup.com"
}

• The sub claim is set to CHRISMALEK which is the OPRID that the JWT token is mapped to.
• The email claim is set to chris.malek@cedarhillsgroup.com which is the email address for the OPRID in the sub claim.

If both of these do NOT match then the authentication will not work and the web service will NOT run..

Let see if we change the casing on the email address in PeopleSoft from chris.malek@cedarhillsgroup.com to Chris.malek@cedarhillsgroup.com (capital C) and then try to run the service again.

GET http://34.16.144.215:8000/PSIGW/RESTListeningConnector/PSFT_CS/CHG_METADATA.v1/ HTTP/1.1
accept-encoding: gzip, deflate, br
accept: application/json
authorization: Bearer eyJraWQiOiJKRnF1MExEOWIxWEJLSV9ZLS1MRlpiQmN6ZFNiZGdMSURxVzBoSkhaWWtRIiwiYWxnIjoiUlMyNTYifQ.eyJ2ZXIiOjEsImp0aSI6IkFULlhTNDY4ZlZ0a2RGTmNQdWxqMWJwNl9SUEdCWjkxLUxqcXJrd1BlT2trdTQiLCJpc3MiOiJodHRwczovL2Rldi0xMjY1MTkub2t0YXByZXZpZXcuY29tL29hdXRoMi9hdXMyOXp3ZTh3cThTVmw4ODBoOCIsImF1ZCI6ImNoZy10ZXN0IiwiaWF0IjoxNzM0MTIyODU5LCJleHAiOjE3MzQxMjY0NTksImNpZCI6IjBvYTI5eHBzcGxua2xTS0F5MGg4IiwidWlkIjoiMDB1NXJxaDR0bEkya3ZvczMwaDciLCJzY3AiOlsib3BlbmlkIl0sImF1dGhfdGltZSI6MTczNDEwOTc2Niwic3ViIjoiQ0hSSVNNQUxFSyIsImVtYWlsIjoiY2hyaXMubWFsZWtAY2VkYXJoaWxsc2dyb3VwLmNvbSJ9.R9yzqIijo4hD8fooiOMjT_ZVUYDOXLDA_05gfTErcU8EJYHQyG3Npkj-Tg4XLE3DJvMnJohPsKFdrj65nWgKTMyxGQTawSgKJzuu4sMWGbt87L9yf-VabvrUMxNLmSpTNygXSemj8Gy5zxR8qrdHs5pRMHZfd4PQy-dFzV9r7RFG2ilBkJW6BPLc1-YuySSwYG1aAFvin1bluTpJLaTPn5i08btj08SGfpzAYP_gRQLlmj-puF3reSSxYB5hOZ08ZA2SoNhCLyBJXftGjz27wvpsNw0iM1CIKziNmO1JbT-okN5oA2AXPsEvSQwfUZG7ZUNE6Uy8E5s9B65QrwGHIA
user-agent: httpyac

HTTP/1.1 401 Unauthorized
cache-control: no-store, must-revalidate, private
connection: close
content-length: 0
date: Fri, 13 Dec 2024 21:15:19 GMT
www-authenticate: Bearer realm="PeopleSoft Enterprise PeopleTools", error="invalid_token"
x-oracle-dms-ecid: 5c8484a0-32b4-4ec3-b376-56dab4e1f77d-000001ba
x-oracle-dms-rid: 0

If we look at the errorLog.html we will see two messages that are not super helpful.

Invalid Access Token Passed as part of request: OAUTH2 Authentication failed for Service Operation CHG_METADATA.v1. (158,461)

That is a bit confusing because the token is valid. The problem is that the email address in the JWT token does not match the email address in the PSUSEREMAIL table for the OPRID in the sub claim. It does NOT tell you this anywhere.

In the application server log you will see some cryptic message that points to the problem. However, if you did NOT notice that the casing was different you would not know what the problem was.

(1) PSOAuth2: isInboundOAuth2Subject function: Failed to find Peoplesoft User for OAuth2 User <
(5) PSOAuth2: Payload String is empty.
(1) PSOAuth2: isInboundOAuth2Subject function: Failed to find Peoplesoft User for OAuth2 User <chris.malek@cedarhillsgroup.com>.
(1) PSOAuth2: OAuth2 user is not exist in peoplesoft env!

If we change the Service Operation “Req Verification” to OAuth2 it will still work but now the Basic Authentication will NOT work. This is because the service operation is now set to only accept the JWT token.

In my testing, if you try to do Basic Authentication with the service operation set to OAuth2 the web service send back an HTTP response like this:

HTTP/1.1 401 Unauthorized
cache-control: no-store, must-revalidate, private
connection: close
content-length: 0
date: Fri, 13 Dec 2024 22:04:49 GMT
www-authenticate: Bearer realm="PeopleSoft Enterprise PeopleTools", error="invalid_token"
x-oracle-dms-ecid: dd289cd9-8ec9-4d2e-b4a1-1868bf4cb208-0000003f
x-oracle-dms-rid: 0

• Recommendation So I would keep the service operation set to NONE as long as your ANONYMOUS node is secure. (See the Properly Securing the ANONYMOUS IB Node
  • Using NONE does NOT mean there is no authentication.