It's my current understanding that on a PASOE web server - after authenticating a user against AD, LDAP, etc. - that Progress implicitly creates a Client Principal object or token. Well, that is if you have your oeablSecurity.properties file's OEClientPrincipalFilter.enabled set to true. Is it best practice to use this implicitly created token for each user session or is it optimal to explicitly create a token to enact SSO? Also, if it is acceptable to use the implicitly created token do you rely purely on the OEClientPrincipalFilter settings that are contained in the oeablSecurity.properties file?
The only token that PASOE/Spring passes into an ABL session is the CLIENT-PRINCIPAL. So if you want to use that token in your ABL sessions - and I firmly believe you should - then you should always have this enabled.
Note that this only passes the token into the ABL session: it does *not* assert the user in the session (you need to code that via SET-DB-CLIENT() or SET-CLIENT()).
The only token that PASOE/Spring passes into an ABL session is the CLIENT-PRINCIPAL. So if you want to use that token in your ABL sessions - and I firmly believe you should - then you should always have this enabled.
Note that this only passes the token into the ABL session: it does *not* assert the user in the session (you need to code that via SET-DB-CLIENT() or SET-CLIENT()).
We do recommend that you allow OE to create and seal Client-Principal security tokens, whether via the OE Database connection, PASOE, or the OE Authentication Gateway. The property OEClientPrincipalFilter.enabled exists in the PASOE configuration solely for the ability to turn it off for the rare exception case. The default is true to support the recommend practice.
There are a number of properties in the oeablSecurity.properties file that allow for customization of the PASOE generated Client-Principal's contents. That configuration file exists in the protected area of the server where it is not accessible from clients or application code - therefore it can be trusted.
Just a side-note: the use of the OE Authentication Gateway by PASOE to create and seal Client-Principal security tokens gives you even more security isolation and a greater ability to use ABL to affect the contents of the Client-Principal object To the business application, the origin and sealing of a Client-Principal becomes transparent.
The generated Client-Principal token is pushed to the ABL Session on each client request - regardless of its origin. In the application it can be ignored, used by the business application, or used to control the OE database connection's user per the application's security model.
More information, but if you looking at this aspect of PASOe it may help to have a broader view.
Thanks for the responses Michael and Peter. I went ahead asserted the user using the SET-DB-CLIENT().
However, I am still a bit lost on the subject of SSO with the CLIENT-PRINCIPAL. In my oeablSecurity.properties file should I have the client.login.model set to "basic" or "sso". Ideally, I would like this to be SSO with my http.all.authmanager set to "ad".
To clarify - I have a PASOE web service setup with this config:
http.all.authmanager = ad
client.login.model = basic
OEClientPrincipalFilter.enabled=true
OEClientPrincipalFilter.key=
OEClientPrincipalFilter.registryFile=
OEClientPrincipalFilter.domain=
OEClientPrincipalFilter.roles=
OEClientPrincipalFilter.authz=true
OEClientPrincipalFilter.expires=28800
OEClientPrincipalFilter.accntinfo=false
OEClientPrincipalFilter.ccid=false
OEClientPrincipalFilter.anonymous=false
OEClientPrincipalFilter.sealAnonymous=false
OEClientPrincipalFilter.appName=OE
OEClientPrincipalFilter.passthru=false
OEClientPrincipalFilter.domainRoleFilter=
OEClientPrincipalFilter.loadAccntAttrList=
Along with my properties for AD configured accordingly. The Web Service does not accept any input parameters. It authenticates and authorizes with these settings when I fire off the request in postman. However, if I hit the endpoint again I still have to provide user credentials for the basic authentication. I assume this is intended as I have client.login.model = basic. However, if I switch to client.login.model = sso I am confused about the process of authentication against ad. I apologize in advance as I know this is likely a basic concept that I am overlooking. Any links to documentation, input, etc. would be greatly appreciated.