I have managed to get REST authentication via OERealm to work using the existing _user table and a class that does user & password authentication. The user & password are in the header and are base64 encoded. A client principle is then created and use by an appserver activation procedure.
I can also just read the header and authenticate each request without OERealm at the point when my method is run on the appserver and use setuserid.
What is the benefit in this case of using OERealm spring security?
As far as I can see it makes 3 appserver requests - user validation, password validation, run my method compared with 1 appserver request if authenticate is part of running the method.
If the user was not in_user then the client principal would be need as setuserid could not be used.
Thanks.
Hello Carl,
There are a number of considerations to make when choosing your application's authentication & authorization processes. I think your question is not about using OERealm specifically. The way it is worded the question is about choosing to use the Spring Security framework OpenEdge embeds within their REST and PASOE services - versus writing security services in ABL within your application. ( But I could be wrong and am answering the wrong question )
. The Spring Security framework implements best-practice authentication and URL authorization processes, with hundreds of thousands of hours in production systems - so it lends a level of security above what the normal application developer can provide.
. Using Spring Security forces ALL client requests through a single point where user identity is validated and authorized to execute your ABL code BEFORE it executes - therefore protecting your code from many of the possible attacks you would have to manually code into your ABL application. It is becoming a best practice to NOT write the authentication and URL authorization into the business application code.
. OERealm is just one of a number of configurable choices for where your REST service's authentication does account validation. You can change OERealm out and reconfigure to use LDAP, Active Directory, SQL server, SAML, openID, or a host of other user account authentication providers without changing your ABL application code - the Client-Principal being the common binding between the security layers and your business logic
. The same applies for your choice of wire protocol and login session models should you want to go with something better than the HTTP BASIC one. Reconfigure and Spring Security handles login sessions and login session security without changes to your ABL application - the Client-Principal being the common binding between the security layers and your business logic
There can be more, but consider these to see if I have answered your question adequately.
Mike Jacobs
Hi Carl,
You can use OERealm Spring Security to send a anonymous request to the OERealm ABL Class or a valid client-principal. A valid client-principal can be sent by configuring "realmTokenFile" property in "OERealmUserDetails". This will help in validating the identity of the user who is trying to access the OERealm Class and validate the user identity
> On Apr 13, 2016, at 9:25 AM, carl.williams wrote:
>
> ... in the header and are base64 encoded. ...
note that this is no better than clear text.
We are using https to allow for clear text user & password. Can anyone comment on advantages of OERealm in the original post. Thanks.
Hello Carl,
There are a number of considerations to make when choosing your application's authentication & authorization processes. I think your question is not about using OERealm specifically. The way it is worded the question is about choosing to use the Spring Security framework OpenEdge embeds within their REST and PASOE services - versus writing security services in ABL within your application. ( But I could be wrong and am answering the wrong question )
. The Spring Security framework implements best-practice authentication and URL authorization processes, with hundreds of thousands of hours in production systems - so it lends a level of security above what the normal application developer can provide.
. Using Spring Security forces ALL client requests through a single point where user identity is validated and authorized to execute your ABL code BEFORE it executes - therefore protecting your code from many of the possible attacks you would have to manually code into your ABL application. It is becoming a best practice to NOT write the authentication and URL authorization into the business application code.
. OERealm is just one of a number of configurable choices for where your REST service's authentication does account validation. You can change OERealm out and reconfigure to use LDAP, Active Directory, SQL server, SAML, openID, or a host of other user account authentication providers without changing your ABL application code - the Client-Principal being the common binding between the security layers and your business logic
. The same applies for your choice of wire protocol and login session models should you want to go with something better than the HTTP BASIC one. Reconfigure and Spring Security handles login sessions and login session security without changes to your ABL application - the Client-Principal being the common binding between the security layers and your business logic
There can be more, but consider these to see if I have answered your question adequately.
Mike Jacobs
Thanks for the answer it was very helpful and clear.