OE12 and OERealm - is it working?

Posted by Darren Parr on 11-Apr-2019 19:26

Hi

Just tried to setup basic authentication and oerealm and its not working. Any idea if there are major changes I should know about.

I've been through the KB article and setup what I think I need. I had to add the CP access code as the key property was missing by default.

oeablSecuritry.properties (pas/conf)

http.all.authmanager=oerealm

client.login.model=basic

OEClientPrincipalFilter.domain=STYLEsso

OEClientPrincipalFilter.key=oech1::<nowayimtellingyouthis> (I had to add this entry)

OERealm.AuthProvider.multiTenant=false

OERealm.UserDetails.realmURL=localhost:10000/apsv    (cant use nxgas for some reason)
OERealm.UserDetails.realmClass=OSL.Security.Realm.HybridRealm

OERealm.UserDetails.realmTokenFile=oespaclient.cp (tried multiple locns for this file common/lib and WEB-INF/classes)

It doesn't work I'm afraid. Any ideas? I'm sure I've missed something obvious.

-D 

Posted by Irfan on 11-Apr-2019 20:51

Hi Darren,

From 12.0, we have removed "keys". You will have to use the registryfile instead of keys from now on.

All Replies

Posted by Irfan on 11-Apr-2019 20:51

Hi Darren,

From 12.0, we have removed "keys". You will have to use the registryfile instead of keys from now on.

Posted by Darren Parr on 11-Apr-2019 22:48

Thanks. Is that all that's wrong? ie Am I missing anythihng else?

-D

Posted by Irfan on 12-Apr-2019 10:22

That should be it. Generate your domain-access codes using genpassword and use try it.

Posted by Darren Parr on 13-Apr-2019 00:05

OK. I've got it working to a point. Ive switched to form based authentication.

My HybridRealm class runs and it all comes back ok so that it all works fine. It validates users correctly and its all secured. However I'm expecting a new CP to be generated with a domain against the OEClientPrincipalFilter. Is that done automatically on the next request or should I be seeing some interaction to the appserver after the JSESSIONID is returned ?

Alternatively do I need to create a new CP just before a successful return of ValidatePassword and set that to the session.

OEClientPrincipalFilter.enabled=true

OEClientPrincipalFilter.registryFile=ABLDomainRegistry.keystore

OEClientPrincipalFilter.domain=STYLEsso

OEClientPrincipalFilter.roles=

OEClientPrincipalFilter.authz=true

OEClientPrincipalFilter.expires=0

OEClientPrincipalFilter.accntinfo=false

OEClientPrincipalFilter.ccid=false

OEClientPrincipalFilter.anonymous=false

OEClientPrincipalFilter.sealAnonymous=false

OEClientPrincipalFilter.appName=OE

OEClientPrincipalFilter.forwardToken=false

OEClientPrincipalFilter.passthru=false

OEClientPrincipalFilter.domainRoleFilter=

OEClientPrincipalFilter.loadAccntAttrList=

-Darren

Posted by Darren Parr on 15-Apr-2019 12:11

The issue seems to be an incompatibility as they are shipped between the oeablSecurity.properties files. The files in conf and locally don't work well unfortunately. I've fixed this by disabling the OEClientPrincipalFilter in the local file. Unfortunately the OERealmAuthProvider setting in conf is sealing the CP so the OEClientPrincipalFilter doesn't work. There is not setting for the seal against the OERealmAuthProvider in the <WEB-INF> version so unless you add it and set it to false, you cant use the OEClientPrincipalFilter.

So in short I disabled the OECP altogether and set the correct registry file and domain in the local OERAP. This way I'm using a  default conf file.

Posted by Michael Jacobs on 16-Apr-2019 10:05

Hello Darren,

We will certainly look at the consistency of the 'scoped' default values in the oeablSecurity.properties files for version 12.  

In general the ClientPrincipal filter configuration properties are used for authentication providers that do not produce a ClientPrincipal object that can be sent to the ABL application.  Examples would be LDAP, AD, OAuth2, or SAML2.    The OERealm authentication provider is slightly different because it does provide a richer API that allows your ABL code to provide information we can use as direct input to generating a sealed ClientPrincpal object.  So OERealm contains a set of properties that allows this one-step creation and seal process to be performed.  A contributing factor is the timing of when the OERealm authentication provider runs in the authentication process.  Using the ClientPrincipal filter's configuration to inject the correct HTTP session id and do the seal operation was found to be faulty - therefore the OERealm is self contained and does its own seal operation.

We'll also look at the documentation for clarity on the relationship between ClientPrincipal configuration properties and the OERealm authentication provider.

A final question:  could you help us out by supplying the oeablSecurity.properties files for the PASOE instance (conf/), the ABL application (ablapps/xxx/conf/), and the web application's WEB-INF/?   I understand if that is confidential information and you do not want to share... but it does help us to see live problem cases.

Mike Jacobs

Posted by Mike Fechner on 24-Apr-2019 20:26

[quote user="Irfan "]

That should be it. Generate your domain-access codes using genpassword and use try it.

[/quote]

Hi Irfan, how do I use genpassword to generate the ABLDomainRegistry.keystore file?

Where do I find that documentation or a sample?

Posted by Matt Baker on 24-Apr-2019 20:54

Mike,

gendomreg utility is used to generate java keystore to hold the domain registry which is what the 'OEClientPrincipalFilter.registryFile=ABLDomainRegistry.keystore' property is referring to.  Doc is here:

documentation.progress.com/.../index.html

gendomreg accepts a .csv and spits out a binary file that is encrypted.  You can use any file name as there isn't  standard for it.  The encrypted keystore file is there to avoid having cleartext domain registry keys lying around in your config.

The client principal filter uses the keystore file (it can't use the .csv file) to find the domain registry key to seal the client principal.

Posted by Mike Fechner on 24-Apr-2019 21:24

Thanks, Matt!

Sent from Nine

Von: Matt Baker <bounce-mbaker@community.progress.com>
Gesendet: Mittwoch, 24. April 2019 22:55
An: TU.OE.Development@community.progress.com
Betreff: RE: [Technical Users - OE Development] OE12 and OERealm - is it working?

Update from Progress Community
Matt Baker

Mike,

gendomreg utility is used to generate java keystore to hold the domain registry which is what the 'OEClientPrincipalFilter.registryFile=ABLDomainRegistry.keystore' property is referring to.  Doc is here:

documentation.progress.com/.../index.html

gendomreg accepts a .csv and spits out a binary file that is encrypted.  You can use any file name as there isn't  standard for it.  The encrypted keystore file is there to avoid having cleartext domain registry keys lying around in your config.

The client principal filter uses the keystore file (it can't use the .csv file) to find the domain registry key to seal the client principal.

View online

 

You received this notification because you subscribed to the forum.  To unsubscribe from only this thread, go here.

Flag this post as spam/abuse.

Posted by Thomas Hansen on 25-Jul-2019 13:12

Has the online documentation been updated to show a correct setup?

If anyone has a set of oeablSecurity.properties sample files for a pasoe instance they would be willing to share, that would be great. I am working on an upgrade to an 11.7 setup without domains defined by default, using OERealm and struggling to get it to work properly. So a good set of reference files would be very welcome.

Posted by Thomas Hansen on 26-Jul-2019 10:36

Am I understanding correctly that even if you don't have domains defined in your database and want to use OERealm, that a key file has to be generated? Or can the standard one be used for this purpose?

Is there a doc or guide somewhere that describes how to set this up for a database that is not using _user (has a separate OE user table), and does not have any specific domains defined - but is set up with a custom HybridRealm.cls intended to initially use OERealm and possibly other authentication providers.

As I mentioned in my previous comment, we have a working 11.7 setup - but cannot get it to work on OE 12. We keep getting errors about passwords being mismatched between the spaservice.properties file and the .cp file generated using genspacp when trying to log on.

Anyone successfully been able to get this working?  

Posted by Mike Fechner on 26-Jul-2019 11:34

Hi Thomas, this is working for us. But yes, we've had to generate the key file.

Our demo/dev DB is not multi-tenancy. But we use a CP with a login domain (which we use to identify the login company).

Posted by Peter Judge on 26-Jul-2019 13:46

Also, per docs.progress.com/.../Client-principal-updates.html  you *cannot* use a C-P sealed in 11.7 with 12.0.
 
The algorithm used to seal the CP has been updated. You'll also need to generate a new key file for 12.
 
 
 

Posted by Thomas Hansen on 26-Jul-2019 14:21

yeah - I have seen that. Our initial tests showed the files to be identical on a binary comparison though.

But - with newly generated cp files and also a keystore file with an "empty" domain and an additional dummy domain do not work.

So something else is going on...

Posted by Thomas Hansen on 29-Jul-2019 21:38

I may be overlooking something here - but it looks like I have to decode the password that I get from the spaservice.properties before I can use it to do a

VALIDATE-SEAL(password)

to validate the CP coming from Spring. Is that correct?

If I replace the password I get from OEREalm and just use the plain text password I entered initially, I can actually get the CP validated....

Posted by Thomas Hansen on 30-Jul-2019 07:27

Does this actually mean that the current documented approach of creating a signed .cp file and the associated spaservices.properties file is no longer valid for OE 12?

Or - does it actually mean that my .cp file is not being picked up and used as expected to validate the seal of the CP coming from Spring? 

Posted by Peter Judge on 30-Jul-2019 13:08

The domain's access key (DAC, where C=Code) is used to validate a CP (token). Once sealed , the user's password is not kept in the CP.
 
If you're using 11.1+ then the application ABL should never use the domain access code directly - it's stored in the _Sec-auth-domain record.
 
The DAC values must be the same for all components in the application that create or consume a CP (spring, _sec-auth-domain, generatecp).
 
 
 

Posted by Peter Judge on 30-Jul-2019 13:08

The approach should be the same , but you can't use a CP  generated/sealed in 11.7 with a 12.0+ consumer .
 

Posted by Thomas Hansen on 30-Jul-2019 21:28

I'll have to double check again, as I must be doing something wrong if the proces is the same as for 11.7.

We are using a new .cp file generated with OE 12, and a spaservices.properties file that has been updated with the password from generatecp (the encrypted password is actually the same as for OE 11.7)

The ABL code we are using to validate the CP from Spring was using the OE encrypted password that is created during the .cp file creation as part of the seal validation - and works fine for OE 11.7.4.

I have tried adding the encrypted password on the default (blank) domain from Data Admin Security, Domains - but keep getting an error that the domain registry is empty if I try and use CP:VALIDATE-KEY() (without password).

The sample code attached to the kbases I have looked at also use the password from the spaservices.properties file.

I am really missing clear and concise documentation that goes through and describes the settings needed to implement basic OERealm - but for OE 12 only. I can find docs and kbases that describe setups for various versions of OE - "including" 12.0. But they refer to files that are not there or should not be modified any more in 12. So it almost looks like the 12.x support has just been added in some places by updating the header of the kbases - without validating the content ;-)

If someone can point me to the missing docs (that I may be overlooking) or a list of the steps to go through and validate the setup, I would be most grateful.

Posted by pwokke on 31-Jul-2019 06:43

When you use an encrypted password string to seal an CP or tray the validate-seal on a CP with and encrypted string it works in 11.7.

In 12.0 this does not work well.

On the CP:SEAL an error is thrown up: SAEL failed because encoded domain-access-code is not allowed (14540).

Looks like the use of encrypted strings (convert to decrypted) is not working well under 12.0.

We have logged a case on this at support.

Posted by Thomas Hansen on 31-Jul-2019 06:49

Thanks for letting me know! Do you have a case number for this?

What is the work-around for this at the moment? Storing the CP password in the spaservices.properties file in clear text?

This thread is closed