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.