Use Case for modifying an existing client-principal (CP) token (Generated by Spring Security) to contain a different USER-ID attribute:
Here is a code snippet that seems to accomplish the goal:
DEFINE VARIABLE hCP AS HANDLE NO-UNDO. lok = hCP:VALIDATE-SEAL("sso"). hCP:INITIALIZE(hCP:QUALIFIED-USER-ID). hCP:USER-ID = newID. hCP:DOMAIN-NAME = "hamsters.com". hCP:SESSION-ID = SUBSTRING(BASE64-ENCODE(GENERATE-UUID), 1, 23). hCP:SET-PROPERTY ("role", former + " emulating " + newID). hCP:SEAL ("progress"). SET-DB-CLIENT(hcp, "database").
After making an HTTP request to the service that executes the code above and outputting (to a text file) the CP information - the desired changes appear to work.
Herein lie my dilemmas... the original CP generated by Spring Security still exists and can be used. Which, seems to indicate that the code above did not manipulate the original CP, but created a new CP? Also, the "value", for lack of a better term, of the CP does not appear anything like the Spring Security CP (access token) that is originally returned upon authentication. Is this because I need to BASE64-ENCODE() it? Lastly, is this something that can/should be done in this situation? Alternatives?
Oh, the overall application is a collection of PASOE RESTful web services with a JSDO catalog that is being interfaced by an Angular application via good ole HTTP in conjunction with the JSDO.
Apologies, if there are any misnomers in the terminology or downright conceptual shortcomings. I'm more than happy to provide any details I may have excluded and thankful for any input from the community.