OERealm REST Authentication

Posted by Paul Koufalis on 07-Aug-2014 16:05

OE 11.3.2

I am looking for some guidance regarding OERealm authentication.  I have read the documentation and the SPAInstructions.pdf and it's still not 100% clear.

This is what I have done:

  • Copied hybridrealm.cls, properties.cls to sp2krealm.cls and sp2krealproperties.cls
  • Modified them accordingly for the new names
  • Copied these and spaservice.propertiesto the PROPATH of my state-free APSV
  • Changed appSecurity-basic-oerealm to point to my apsv
  • I only changed AppServer and realmClass under OERealmUserDetails
  • Change web.xml to use appSecurity-basic-oerealm
  • Added usernames and passwords to the sp2k DB to which the Apsv is connected
  • Turned on debugging in log4j.prop

When I attempt to access my rest service, I get a username/password popup which does not accept my sp2k._USER username and password.

What I see in the apsv.server.log:

14/08/07@16:21:51.135-0400] P-007408 T-009196 1 AS -- (Procedure: 'LoadProps sp2kRealmProperties' Line:91) Loading properties from file: spaservice.properties
[14/08/07@16:21:51.135-0400] P-007408 T-009196 1 AS -- (Procedure: 'LoadProps sp2kRealmProperties' Line:95) Opening properties file: C:\Apps\OpenEdge\oe113_wrk\sports\spaservice.properties
[14/08/07@16:21:51.135-0400] P-007408 T-009196 1 AS -- (Procedure: 'LoadProps sp2kRealmProperties' Line:98) Loading properties file: C:\Apps\OpenEdge\oe113_wrk\sports\spaservice.properties
[14/08/07@16:21:51.135-0400] P-007408 T-009196 1 AS -- (Procedure: 'LoadProps sp2kRealmProperties' Line:106) Loaded property with value:
[14/08/07@16:21:51.135-0400] P-007408 T-009196 1 AS -- (Procedure: 'LoadProps sp2kRealmProperties' Line:106) Loaded property DebugMsg with value: true
[14/08/07@16:21:51.136-0400] P-007408 T-009196 1 AS -- (Procedure: 'LoadProps sp2kRealmProperties' Line:106) Loaded property Password with value: oech1::20333c34252a2137
[14/08/07@16:21:51.136-0400] P-007408 T-009196 1 AS -- (Procedure: 'LoadProps sp2kRealmProperties' Line:106) Loaded property Role with value: SpaClient
[14/08/07@16:21:51.136-0400] P-007408 T-009196 1 AS -- (Procedure: 'sp2kRealm sp2kRealm' Line:25) Loaded property file spaservice.properties
[14/08/07@16:21:51.136-0400] P-007408 T-009196 1 AS -- (Procedure: 'sp2kRealm sp2kRealm' Line:25) Password: oech1::20333c34252a2137
[14/08/07@16:21:51.136-0400] P-007408 T-009196 1 AS -- (Procedure: 'sp2kRealm sp2kRealm' Line:25) Role: SpaClient
[14/08/07@16:21:51.136-0400] P-007408 T-009196 1 AS -- (Procedure: 'sp2kRealm sp2kRealm' Line:25) DebugMsg: True
[14/08/07@16:21:51.136-0400] P-007408 T-009196 1 AS -- Unauthorized client

and in my webapp...adapter\log:

2014-08-07 16:22:51,341 567461 [http-bio-8980-exec-64] DEBUG com.progress.rest.security.OERealmAuthProvider retrieveUser - Retrieving OERealm user account: pk
2014-08-07 16:22:51,341 567461 [http-bio-8980-exec-64] DEBUG com.progress.rest.security.OERealmAuthProvider retrieveUser - Retrieving OERealm user account: pk
2014-08-07 16:22:51,341 567461 [http-bio-8980-exec-64] INFO com.progress.rest.security.OERealmUserDetailsImpl loadUserByUsername - Loading user account: pk
2014-08-07 16:22:51,341 567461 [http-bio-8980-exec-64] INFO com.progress.rest.security.OERealmUserDetailsImpl loadUserByUsername - Loading user account: pk
2014-08-07 16:22:51,341 567461 [http-bio-8980-exec-64] DEBUG com.progress.rest.security.OERealmUserDetailsImpl loadUserByUsername - Locating OERealm user: pk
2014-08-07 16:22:51,341 567461 [http-bio-8980-exec-64] DEBUG com.progress.rest.security.OERealmUserDetailsImpl loadUserByUsername - Locating OERealm user: pk
2014-08-07 16:22:51,347 567467 [http-bio-8980-exec-64] ERROR com.progress.rest.security.OERealmUserDetailsImpl loadUserByUsername - Username load error for pk re: Realm o4gl run-time error: com.progress.open4gl.RunTime4GLErrorException: ERROR condition: Unauthorized client (7211)
2014-08-07 16:22:51,347 567467 [http-bio-8980-exec-64] ERROR com.progress.rest.security.OERealmUserDetailsImpl loadUserByUsername - Username load error for pk re: Realm o4gl run-time error: com.progress.open4gl.RunTime4GLErrorException: ERROR condition: Unauthorized client (7211)
2014-08-07 16:22:51,348 567468 [http-bio-8980-exec-64] WARN com.progress.rest.security.OERealmAuthProvider retrieveUser - User not found: pk
2014-08-07 16:22:51,348 567468 [http-bio-8980-exec-64] WARN com.progress.rest.security.OERealmAuthProvider retrieveUser - User not found: pk
2014-08-07 16:22:51,348 567468 [http-bio-8980-exec-64] DEBUG com.progress.rest.security.OERealmAuthProvider authenticate - User 'pk' not found
2014-08-07 16:22:51,348 567468 [http-bio-8980-exec-64] DEBUG com.progress.rest.security.OERealmAuthProvider authenticate - User 'pk' not found

TIA

OpenEdge Development - Forum

All Replies

Posted by Paul Koufalis on 07-Aug-2014 22:48

After a lot of reading and trial-and-error, I'm 99% there.  I added my own cp in WEB-INF/classes and got all the way to ValidatePassword().  With realmPwdAlg=0 the password is passed in plain text and the validation fails since it checks "_User._Password = password" and _password is ENCODE'd .  If I pass the actual content of _Password it works great.

Of course I could change HybridRealm.cls to authenticate against ENCODE(password) but somehow that doesn't seem like the right solution.

What am I missing?

Posted by Michael Jacobs on 08-Aug-2014 05:39

Hello Paul,

You ask a good question - but because it’s security the response is not always simple:

I’ll point out that the clear-text password value is only one of your problems as clear-text user-ids, privileges, and account attributes carry their own security liability problems.   Its easiest to always pass everything using a secure socket connection via local sockets or using SSL encrypted connections.    You could employ wire encryption and encryption all of the field values individually, but generally is a lot of work to actually make it secure and there are easier ways.

Regarding ENCODE().  Using the ABL ENCODE() function for OpenEdge, or gnu standard password encoding for UNIX, accounts is an example of where a clear-text password is needed so that the OERealm class can use the same encoding algorithm in order to match the stored encoded value.  Calling something like an LDAP/AD service or ABL SET-DB-CLIENT() API would be an example where the user account system’s API requires a clear-text password value.    In either case, the process starts with the OERealm class knowing the clear-text value.   The simple path for many reasons is to simply pass a clear-text value and let the OERealm know what to do with it.

OK?

Mike J.

[collapse]
From: Paul Koufalis <bounce-pkoufalis@community.progress.com>
Reply-To: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Date: Thursday, August 7, 2014 at 11:49 PM
To: "TU.OE.Development@community.progress.com" <TU.OE.Development@community.progress.com>
Subject: RE: [Technical Users - OE Development] OERealm REST Authentication

Reply by Paul Koufalis

After a lot of reading and trial-and-error, I'm 99% there.  I added my own cp in WEB-INF/classes and got all the way to ValidatePassword().  With realmPwdAlg=0 the password is passed in plain text and the validation fails since it checks "_User._Password = password" and _password is ENCODE'd .  If I pass the actual content of _Password it works great.

Of course I could change HybridRealm.cls to authenticate against ENCODE(password) but somehow that doesn't seem like the right solution.

What am I missing?

Stop receiving emails on this subject.

Flag this post as spam/abuse.

[/collapse]

Posted by Paul Koufalis on 08-Aug-2014 08:21

Thanks Mike.  I was thrown off because the documentation made it sound like the example hybridrealm.cls was fully functional but it is not.  I felt that if I had to modify the hybridrealm class then I was doing something wrong and was attempting to fix the wrong problem.

Is there more documentation?  I did not find much:

1. OpenEdge Application Server:Administration : REST Management Agent and REST Web Application Security Configurations

2. src/samples/security/SPAInstructions.pdf

3. Searching for "OERealm" on communities where I found a few of your posts

Is there anything else?  

And if I may hijack my own post: my next question is about CORS and JSON vs JSONP in a REST application.  What I accidentally read so far seems to imply that I can *fix* something in appSecurity-*.xml to allow cross-domain REST calls.  But isn't this blocked by the browser?  Note that i fully admit that I have not RTFM'd yet - I'm just fishing for info before doing the legwork myself!

Regards,

Paul

Posted by Michael Jacobs on 08-Aug-2014 10:25

We have newer documentation coming out for the OERealm functionality.   That should help fill in some of the blank areas the first versions had.

One of the issues was setting the expectations regarding what the 'sample' provided and did not provide.   The sample provided direction - but not implementation or an example of what could truly be accomplished using the OERealm functionality.    We did not do a good job at that.  As more PSC products use the OERealm functionality, you should see a marked improvement.

CORS... and there begins an entire discussion.   Yes, the REST services include a built-in standards compliant CORS security module that you can customize per the production site's requirements.   The default is mostly *open* but is not * open - open*, if you get my meaning.   You adjust the CORS configuration in the appSecurity-*.xml files.

The client JavaScript engines I've seen implement domain security to block cross-site scripting attacks by the code.  However, cross-site access is necessary and we needed a controllable access method.   The JASON-P, in my opinion, is a hack.  The CORS spec is I think a better answer:   In the CORS model the client sends a 'captain may I..." to the server, and the server's CORS module responds with a "Yes, but only to these things" or a "NO - go away"  response.   The javaScript engine then control's the code's access to resources based on the server's response.    The REST's CORS module allows you to control which clients (IP addresses), which http methods, which request headers, and which response headers.   It still comes down to a synchronization of the client code's requirements and the server being configured to meet those requirements.

Better?

Posted by Paul Koufalis on 08-Aug-2014 10:30

Yes better!  :-)

I am definitely looking forward to any new documentation.  I am struggling through trial-and-error for every little thing.

Paul

Posted by Thomas Mercer-Hursh on 08-Aug-2014 10:43

Seems like Paul would be a good person to test out a draft of the new documentation ...

This thread is closed