Use Case for modifying an existing client-principal (CP) token (Generated by Spring Security) to contain a different USER-ID attribute:

  • Two mechanisms by which users can be authenticated and hereby authorized to a group of data services
    1. AD/LDAP acts as a point of authentication for a set of employees - returns the Spring Security iteration of the CP.
    2. OERealm acts as a point of authentication for a set of customers - returns the Spring Security iteration of the CP.
  • The employees need to emulate the customers because the queries for data services are built on the USER-ID attribute of CP.

Here is a code snippet that seems to accomplish the goal:

 lok = hCP:VALIDATE-SEAL("sso").
 hCP:USER-ID = newID.
 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.