OE12 and OERealm - is it working? - Forum - OpenEdge Development - Progress Community

OE12 and OERealm - is it working?

 Forum

OE12 and OERealm - is it working?

This question is answered

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 

Verified Answer
  • Hi Darren,

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

    Regards,

    Irfan

All Replies
  • Hi Darren,

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

    Regards,

    Irfan

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

    -D

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

    Regards,

    Irfan

  • 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

  • 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.

  • 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

  • Irfan

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

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

    Where do I find that documentation or a sample?

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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.

  • 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.

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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.

  • 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?  

  • 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).

    Architect of the SmartComponent Library and WinKit

    Consultingwerk Ltd.

  • 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.
     
     
     
  • 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...

  • 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....