OpenEdge Authentication and
Rollbase
1.
OpenEdge SPA Architecture ......................................................................................... 1
2.
OpenEdge SSO Architecture ......................................................................................... 2
3.
Implementing OEREALM Service Interface for Rollbase ................................... 2
3.1
Optional security for OERealm Service Interface ............................................. 3
4. Configuring Rollbase to use OE REALM interface as a Single Point of
Authentication ........................................................................................................................... 4
5.
The Process flow .............................................................................................................. 5
6. Configuring REST Service for pre-authenticated Single Sign On (SSO) from
Rollbase ........................................................................................................................................ 5
7.
Debugging REST Service ................................................................................................ 7
1. OpenEdge SPA Architecture
The OpenEdge Single Point of Authentication (not to be confused with OpenEdge’s
Single Sign-On functionality) was developed to allow external user authentication
processes to access a common AppServer interface as a source of user account
information. In that way the application’s users can use a single user account and
password to access any facet of the application, and administrators have only a
single user account system to maintain. The AppServer’s SPA interface allows the
external authentication process access to such items as:






User account lookup
User account attribute retrieval
User account password validation
Listing of all user accounts
Listing of user account attributes
<and so forth>
The first OpenEdge component to support an AppServer SPA interface is BPM, with
the REST/Mobile services as the second adopters. As time progresses, other
Progress components will be integrated with the AppServer’s SPA interface.
The actual code running in back of the AppServer SPA interface is referred to as an
OERealm, and is developed and written by the ISV/DUE development team.
OpenEdge supplies a simple example, but the implementation has to be as
proprietary as the IdM system it accesses.
2. OpenEdge SSO Architecture
Starting in release 10.1 OpenEdge integrated support for a proprietary securitytoken that formed the foundation of the ABL language’s SSO framework. That
security-token was, and is, referred to as a CLIENT-PRINCIPAL ABL object, which
could be created, transported between distributed components, validated, and used
to establish user identity in database connections and ABL sessions. Please refer to
OpenEdge documentation for learning more about CLIENT-PRINCIPAL (referred to
C-P in this document)
3. Implementing OEREALM Service Interface for Rollbase
1. Configure a State-free AppServer that is required to host the OERealm
service interface class. (let’s say the AppServer name is oerealm, and it is
configured on machine1 with NameServer port as 5162)
2. Create an OO ABL class that implements IHybridRealm (Let’s say the class
name is psc.realm.myRealmClass.cls)
(NB: You can find a sample interface implementation class, HybridRealm.cls,
at $DLC\src\samples\security\OpenEdge\security\Realm)
CONTD….
3. You need to implement at least the following methods:
/*-----------------------------------(1)-----------------------------------------Purpose: Looks up the user account and returns numeric account number
INPUT : 1. fully qualified user name
e.g.:
fred@spadomain or
fred (indicating blank domain)
------------------------------------------------------------------------------*/
METHOD PUBLIC INTEGER ValidateUser( INPUT userName AS CHARACTER )
/*-------------------------------------(2)----------------------------------------Purpose: Does account password validation
INPUT : 1. theUserId – numeric account number
2. password – password text
------------------------------------------------------------------------------*/
METHOD PUBLIC BOOLEAN ValidatePassword (INPUT theUserId AS INTEGER,
INPUT attrName AS CHARACTER ):
/*----------------------------------(3)------------------------------------------Purpose: retrieves an attribute for the specified user account.
INPUT : 1. theUserId – numeric account number
2. attrName – name of the Attribute
(NB: The attrName when using Rollbase as the client to the OERealm interface must
be:
(a) ATTR_ENABLED
(b) ATTR_LOCKED
(c) ATTR_EXPIRED
The return value for above attrName(s)must be a character from the
{T,t,F,f,Y,y,N,n,0,1} set
(d) ATTR_ROLES
The return value for above attrName must be a "" or "xxxx[,yyyy,zzzz]"
e.g. “PSCUser,PSCDebug”
------------------------------------------------------------------------------*/
METHOD PUBLIC CHARACTER GetAttribute( INPUT theUserId AS INTEGER,
INPUT attrName AS CHARACTER ):
3.1 Optional security for OERealm Service Interface
The methods described in previous section can be implemented such that each
method checks if the incoming request has a valid C-P, sealed by a secret key known
only to OERealm Service Interface and its client.
OpenEdge provides a genspacp.bat utility which can be used to create a realm
token file that the implementer of OERealm Service Interface class can generate
and share it with its trusted clients (Rollbase in this case)
4. Configuring Rollbase to use OE REALM interface as a Single
Point of Authentication
The configuration for Rollbase to use OEREALM service interface to perform
authentication is described here
Here is a screen shot of the configuration page
Using the values from above section, here are some sample values:
1. OpenEdge Realm URL – Appserver(S)://machine1:5162/oerealm
2. OpenEdge Realm Class - psc.realm.myRealmClass
3. OpenEdge Domain – If left blank, blank domain will be used
4. OpenEdge Domain Access Code – This is the “key” that will be used by
Rollbase to create a C-P using the account details fetched from OERealm
service Interface.
5. Realm Token File – Needed only if the OERealm Service Interface methods
requires a sealed C-P sent along with each request (as in section 2.1) In that
case it must be the realm token file that is provided by the implementer of
the OERealm Service Interface
6. CA Certificate File – Needed only if your Realm URL is secure and it requires
certificate.
5. The Process flow
There are three players here viz.:
1. OERealm Service Interface
2. Rollbase
3. REST Service
When Rollbase is configured for OpenEdge Authentication, Rollbase uses OERealm
Service Interface to validate the user. It also fetches some attributes like
ATTR_ENABLED, ATTR_LOCKED, ATTR_EXPIRED and ATTR_ROLES for the user. It
then creates a C-P using all these information and seals it with OpenEdge Domain
Access Code configured in Section 3.
While calling a REST Service Rollbase puts the base64 encode C-P in HTTP Header
named X-OE-CLIENT-CONTEXT-ID and sends the HTTP request to the REST Service.
If the REST Service is configured with correct “key” for pre-authenticated SSO (see
section 5), it bypasses authentication and only checks the Roles in order to grant
access to the requested service.
NOTE: The C-P is created only once in Rollbase and sealed. This is the C-P that flows
via the REST Service to the AppServer implementing the ABL classes/procedures for
the REST Service and is used as the SSO token.
6. Configuring REST Service for pre-authenticated Single Sign On
(SSO) from Rollbase
1. You may choose any appSecurity-xxxx.xml (other than appSecurityanonymous.xml) as your security template. Let’s say you chose appSecuritybasic-local.xml
2. Open the ../WEB-INF/web.xml. Look for contextConfigLocation contextparam and specify the chosen template (in our example appSecurity-basiclocal.xml)
<context-param>
<param-name>contextConfigLocation</param-name>
<param-value>
<!-- USER EDIT: Select which application security model to employ
/WEB-INF/appSecurity-basic-local.xml
/WEB-INF/appSecurity-anonymous.xml
/WEB-INF/appSecurity-form-local.xml
/WEB-INF/appSecurity-container.xml
/WEB-INF/appSecurity-basic-ldap.xml
/WEB-INF/appSecurity-form-ldap.xml
/WEB-INF/appSecurity-basic-oerealm.xml
/WEB-INF/appSecurity-form-oerealm.xml
/WEB-INF/appSecurity-form-saml.xml
/WEB-INF/appSecurity-basic-saml.xml
-->
/WEB-INF/appSecurity-basic-local.xml
</param-value>
</context-param>
3. Open the chosen ../WEB-INF/appSecurity-xxxx.xml (in our example
appSecurity-basic-local.xml). Look for the following section:
<!-- The Pre-auth security filter for SSO -->
<b:bean id="OEPreauthfilter"
class="com.progress.rest.security.OERequestHeaderAuthenticationFilter">
<!-- USER-EDIT: To turn on SSO :
1. Set "enabled" property to true
2. For single-domain supply the Domain Access Code as the value
for "key" property
3. For multi-domain supply the absolute path of a
'registryFile' generated using OpenEdge's
$DLC/bin/gendomreg.bat utility as "registryFile" property ->
<b:property name="enabled" value="false"/>
<b:property name="key" value=""/>
<b:property name="registryFile" value=""/>
<b:property name="encoding" value="OECP"/>
<b:property name="headername" value="X-OE-CLIENT-CONTEXT-ID"/>
<b:property name="authenticationManager"
ref="authenticationManager" />
</b:bean>
4. You need to modify only the following two properties:
a. Set enabled property as true
<b:property name="enabled" value="true"/>
b. Set key property to the OpenEdge Domain Access Code as configured
in section 3 (These must match).
NOTE: The value can be <cleartext> or oech1:xxxx where xxxx is the
output generated from OpenEdge’s genpassword.bat utility
(Currently Rollbase supports sealing the C-P with a key value so ensure
that you comment out registryFile section:
<!--<b:property name="registryFile" value=""/>--> )
5. Ensure you restart the Tomcat after the above configuration changes
7. Debugging REST Service
1. Browse to ../WEB-INF/classes folder and open log4j.properties
2. Change the following to DEBUG :
log4j.logger.com.progress.rest.security=ERROR, <webappName>
to
log4j.logger.com.progress.rest.security=DEBUG, <webappName>
3. Browse to ../WEB-INF/adapters/runtime.props
4. Change the serviceLoggingLevel to 4
<bpm:serviceLoggingLevel>2</bpm:serviceLoggingLevel>
to
<bpm:serviceLoggingLevel>4</bpm:serviceLoggingLevel>
5. Restart the Tomcat.
6. Look at ../WEB-INF/adapters/<webappName>.log