OE REST Login WebApp

BTW I'm going to go ahead and try it but in the meanwhile I'm confident people more knowledgeable than me will provide some valuable insite.

Hello Paul,

Using the default configuration, the security token generated by a login process in one web application is not directly usable by the authorization process in a different web application.  That is because the security token is stored in server-side http session storage whose scope is limited to a specific web application (via the http session id cookie exchanged between the web application and http client).

The possibility seems to exists where all of the web applications that are running in the same web server instance can be configured to share a single http session and the http session id cookie, therefore using the same session storage and security token.   I've not tried the configuration as I didn't have the time to reconfigure all of the web application's cookie parameters and work out the details.

There is another possibility, which to use the Tomcat SSO valve.   The general theory is to configure all of the web applications to use the same user account file with BASIC authentication.   The Tomcat valve saves the user-id & password of a successful login and automatically inserts them into the BASIC authentication of other web applications.   It does not get you the same security token - but it may allow you transparent access to multiple web applications.

If you get either of these to work - please pass along the steps you took.

Ahh....nothing in life is simple. Unfortunately I have delivery constraints that will prevent me from attacking this right now but it's definitely on the TODO list.  

I did find this by googling around a bit:

In Spring, SecurityContext by default is stored in HttpSession. Instead you can configure it to store in some shared repository.

So, configuration should be changed to use your own SecurityContextRepository implementation instead of HttpSessionSecurityContextRepository. Once configured, the security framework will look at the Repository which is available to all your web applications.

The Repository can be either a database or a cached server.

Thanks again Mike! I'll add to this post when I get a chance to try this (which might be a while).

I believe you still have to adjust the cookies because it carries the jsessionid that is used to index into the shared storage and grab the SecurityContext - and the default path in cookies is per web application.

One day you'll have to expand on your use case a bit more.   The defaults in PDSOE will want to  generate and publish separate .war files for each service.   Technically you can independently develop individual REST services and then install them into a single .war web application (using the RESTMAN utility).   It's how you build optional REST services into a single web application's URL space.   Perhaps a conversation for another day...

I fully admit that my use-case may be non-existant.  What's driving it is the fact that I have one person developing REST services in PDSOE and another developing the Web UI in ExtJS.  

I think it will be sufficient for the WebUI code to be public but it will need to authenticate to access the REST services, which means calling a login page.  Perhaps it will be sufficient to for the webUI to simply run restapp/static/auth/llogin.html. The generated token will only be for restapp/... but who cares as there will be no security on the webUI app.

This is what I'm going to try first.  If it does not work then I guess I'll need to deploy everything into the same webapp.

Hi Paul,

Most of what I've seen so far is that the UI web application is open, with no security configured.   In a general sense, the user authentication applies to the data source (i.e. the REST resources) that has restricted access.  I've not seen a lot of uses where you log into the UI and then SSO into the data source.

The WebUI generally contains its own login page that POSTs to the REST data service's Spring Security resource (j_spring_security_check), as illustrated in the REST service's login.html page.  The returned JSESSIONID cookie will be passed to the REST service on each subsequent http request.   The REST service's login.html is there for debug unit testing and as an example of what the actual UI would call, not what the WebUI would call.   I think calling the REST service's login.html from the WebUI is the LONG way around and would make it more work to maintain.

For what it's worth: I personally, unless there is some architectural requirement, I like to deploy the UI and REST services in the same web application.   Fewer issues with version compatibility, deployments, configuration, and server resource consumption.  

Hope that is of help,

Mike J.

Hi Mike,

Yes that sounds reasonable and that's how we ended up doing it.  We just added a quick login page to our ExtJS application that POSTs as you say.  

I have a follow-up question though: is there a j_spring_security_* service that I can query to check the validity of my session?  Otherwise my application makes a REST call expecting a JSON payload and instead gets redirected to static/auth/login.html.  I suppose I could trap it but I'm wondering what the elegant best-practice solution is.

I googled around a bit but could not find anything useful.

Sorry for the off topic question but why did you choose ExtJS?

I looked at ExtJS in the past but I really didn't like their framework.

Their samples look good on the outside but I don't think it's a good framework on the inside especially for writing large applications.

Hi Paul,

Good question.  While the client must always check and handle errors when the it accesses REST services, most of the time your REST access will be granted if you first authenticate to the web application.   The mobile services do this 'authentication' check by accessing the web application's '/static/home.html' URL because has the same configured access control as the REST services and the client can check its return status without the need to fiddle with REST service parameters.  

If you don't want the html page '/static/auth/login.htlm' returned for a missing/invalid session - then try adding the 'accept' header with value "application/json" to the http request to '/static/home.html'.   It triggers the Spring modules to return a JSON content and a non-success HTTP status if the session is not authenticated or has timed out.   The response JSON looks something along the lines of:

{ "status_code": 401,

 "status_txt": "Not authenticated" }

"the devil is in the detail"  seems appropriate...

Mike J.

Blichal: My conclusion was the opposite.  I looked at their products (Architect, ExtJS, Touch), tried them out for free and liked them a lot.  The learning curve was very reasonable and I was productive in just a couple of days.  What did you choose that you liked better?  Pacific/RollBase is still a little young, especially considering the supposed combination of OE Mobile in 11.4 (I thnk 11.4 - maybe later).

Mike: Holy Smokes there are A LOT of details.  I really enjoy figuring it out though: it's the fun of discovering new toys and how they work.  But I do wish there was more detailed documentation especially with respect to the content of the appSecurity*.xml files.  Is there such documentation?  Would it be the Spring Security documentation that explains a lot of the options?  Or is most of it custom OpenEdge options?

The appSecurity*.xml files are 90% pure Spring.   About 5% is OE extensions to inject CORS support and AppServer SSO conversion to Client-Principal.  Another 2% is a Spring compliant provider for the OERealm support.  The last 3% is subclassed Spring objects that respond with JSON payloads for authn success, failure, and invalid sessions for JavaScript (JSDO) clients when they accept the type application/json.   Even the OE written Spring beans conform to Spring's framework and configuration file schema.   It's all there in the Spring documentation if one has a requirement for handling special use-cases and intestinal fortitude to dig into the how and why.

General statement: Anything OE written in the appSecurity configurations "should" have documentation that describes its purpose, relationship to Spring security processes, and its configuration options.   I guess filling in the blanks is why this forum exists.  

Continue asking - I'll continue helping you have fun with your new toys.

Mike J.

Sorry, I hit reply instead of forwarding this to some interested friends