Is single sign-on a supported authentication method for Hyland.Services?

[Jeffrey_Seaman]

A third party is developing a system for our customer.  We are currently in a proof of concept stage for integration between the products.  We have configured single sign-on for the web client using SAML 2.0.  We ended up having to create a custom HTTP handler to allow DocPop and FolderPop to work properly as OnBase's SAML support is very limited.

The plan is also to use the API to retrieve some information from OnBase to be displayed within this third party product (for example, workflow queue counts for the signed in user).  The third party product is being developed in Java, so Hyland.Services is the only API that is available.  Does the Hyland.Services API support using single sign-on as an authentication method?  I do not see anything in the 11.0 SDK related to single sign-on under the Hyland.Services documentation.  It only lists the following methods under the Connect request:
Regular OnBase security login
Domain Authentication login (Available in Version 5.2.0+)
NT Authentication login (Available in Version 5.2.0+)
Query-Metered connections (Available in Version 5.0.0+)

If single sign-on is not supported in some way, the only way I can see this working would be if the user provided his or her Novell login credentials.  However, that would be unacceptable to the customer as the user would have already provided his or her credentials when signing into the third party product.  They would like an environment that is strictly single sign-on.

Thanks,

Jeffrey Seaman

[Ian_Cordova]

Hi Jeff,

Hyland.Services does support Single Sign-On but only with the .NET libraries.  The Single Sign-On would not work with the java jar files.  If you have to use java Hyland.Services; could the OnBase API be wrapped into a web service?  Even with that I am not sure if it would work as if I remember Novell is passing the SAML message to this java application.  Is this correct so far?

Thanks,

Ian Cordova

[Jeffrey_Seaman]

Thanks for the quick reply, Ian.  Here's a quick outline of what we ended up having to do after you helped us get SSO up and running a few months back.  The way it works now for the web client is that the user signs into the application which is fronted by Novell Access Manager.  When it needs to create DocPop links, they create links to Novell Access Manager with the DocPop URL as a parameter.

So it will hit something along the lines of https://NAMURL/something?parameter=https://server/AppNet/Pop.Integration&target=DOCPOPURLHERE

So NAM will POST to the custom HTTP Handler (Pop.Integration) with the DocPop URL and the SAML token as parameters.  the HTTP Handler then redirects the request to the DocPop URL that was provided.  This had to be built because the SAML support in OnBase didn't support the RelayState parameter which passed the final destination URL.

The developer of this product is running on Linux with a Java backend for the application.  .Net is not an option for them.  We'd like to avoid building wrappers or bandaids as that just means another possible point of failure (plus it's out of scope).  We already had to build one they could call to generate DocPop checksums.  We'll probably just end up sending them flat files on a scheduled basis with the information they want (document queue counts by user, in this case).

[Ian_Cordova]

Hi Jeff,

There is really not a good or clean SSO solution for the Java app without building some type of wrapper.  Even with that, I think we will still have some issues ensuring that we would authenticate the correct person or even receiving the username. 

I apologize that we couldn't come up with a solution for you and the customer. 

Thanks,

Ian Cordova