Replace current request context client-principal in PASOE RE - OpenEdge Development - Forum

Posted by Mike Fechner on 25-Feb-2016 08:42

Hi,

I am using PASOE 11.6 to handle REST calls with Form based authentication. So the REST manager provides me with a sealed client-principal instance that I can query with

ASSIGN hPrincipal = SESSION:CURRENT-REQUEST-INFO:GetClientPrincipal().

All working fine.

I have a use case, where the user is able to change the login company through an application function. I tried to create a new CP with different user/domain name values and assign that using:

SESSION:CURRENT-REQUEST-INFO:SETCLIENTPRINCIPAL (hNewCP) .

But with the next request, I am still getting the original CP returned.

Is there any way to replace the Tomcat generated CP from ABL code to update it's attributes?

Regards,

Mike

OpenEdge Development - Forum

All Replies

Posted by Fernando Souza on 25-Feb-2016 09:02

You need to set it via SESSION:CURRENT-RESPONSE-INFO and not CURRENT-REQUEST-INFO if you want the C-P to be returned to the client.

Posted by Mike Fechner on 25-Feb-2016 09:12

Thanks Fernando, tried that now. But on the next request, I am still having the old user info in the CP.

DEFINE VARIABLE hNewCP     AS HANDLE NO-UNDO.    
DEFINE VARIABLE hCurrentCP AS HANDLE NO-UNDO.    
    
ASSIGN hCurrentCP = SESSION:CURRENT-REQUEST-INFO:GetClientPrincipal().    
    
CREATE CLIENT-PRINCIPAL hNewCP
    ASSIGN DOMAIN-NAME = "xyz"
           DOMAIN-TYPE = "OEApplication"
           QUALIFIED-USER-ID = "42@xyz"
           ROLES = "ROLE_PSCUser"
           SESSION-ID = hCurrentCP:SESSION-ID 
           USER-ID = "42" .

hNewCP:SEAL ("secretseal") .    
    
    
SESSION:CURRENT-RESPONSE-INFO:SETCLIENTPRINCIPAL (hNewCP) .

Posted by Peter Judge on 25-Feb-2016 09:42

I would expect what you're seeing in 11.6 since the Spring Security layer is in charge of creating and managing/storing the token (C-P).

If you want a different domain then I would expect a whole new authentication process to happen since domains are the cornerstone of OE security.

If "new login company" means "change some attributes/properties but the domain stays the same" then we/OE may want to look further into storing a changed CP under the same key (ie the JSESSIONID).

Posted by Mike Fechner on 25-Feb-2016 09:50

[quote user="Peter Judge"]

I would expect what you're seeing in 11.6 since the Spring Security layer is in charge of creating and managing/storing the token (C-P).

If you want a different domain then I would expect a whole new authentication process to happen since domains are the cornerstone of OE security.

[/quote]

That is the response I was afraid of getting ...

[quote user="Peter Judge"]

If "new login company" means "change some attributes/properties but the domain stays the same" then we/OE may want to look further into storing a changed CP under the same key (ie the JSESSIONID).

[/quote]

I'm using what's currently there in the CP: username and domain and domain translates into a company. So in order to change the company (without needing to re-authenticate the user) I was hoping to replace the CP (which is managed and stored by the sping/rest manager stuff) with a CP with the new values.

So if I get you right - that would require an OE product enhancement? May it be the ability to replace the CP or have additional attributes that spring or the rest manager store for us?

So going with the session-id from the CP and storing the actual login company in a session context DB table might be a quick fix then until that enhancement might be implemented?

Posted by Peter Judge on 25-Feb-2016 10:14

<snip>

May it be the ability to replace the CP or have additional attributes that spring or the rest manager store for us?

The CP has no idea about a company: it knows domains and tenants and roles and properties. Currently you can dynamically set roles (from the auth provider/realm). Soon you will be able to dynamically set properties from a realm (which may help or solve your problem) before the CP is sealed. Would that meet your need? The user would not change domains, but as part of login, you would set the "LoginCompany" property appropriately before the CP is sealed.

So going with the session-id from the CP and storing the actual login company in a session context DB table might be a quick fix then until that enhancement might be implemented?

It would.

Posted by Mike Fechner on 25-Feb-2016 10:30

[quote user="Peter Judge"]

Would that meet your need? The user would not change domains, but as part of login, you would set the "LoginCompany" property appropriately before the CP is sealed.

[/quote]

No. Not at all. We really need to be able to change the values after login. It's a regular function in the menu.

So I'll have to go down the route of storing this in additional session context in the framework DB.

Thanks anyway.

Posted by Peter Judge on 26-Feb-2016 08:26

This might be feasible longer-term, but it'd require a couple of pieces:

1a) a STS (security token service)

1b) capable of making token exchanges (so you'd swap the old-domain token for a new-domain token), and

2) a means of telling the REST service's security layer to SSO/ accept a new token

I'm relatively clear on the requirements for 1) but 2) needs some thought, mainly through the plumbing mechanics.

This thread is closed