OnDemand User Group

Support Forums => Windows Client => Topic started by: wdssnyder on June 20, 2019, 09:45:53 AM

Title: Single sign-on for client
Post by: wdssnyder on June 20, 2019, 09:45:53 AM
Company using thick client v9.5.0.3. Is there any version of thick client, where single sign-on is available?
Title: Re: Single sign-on for client
Post by: Justin Derrick on June 22, 2019, 04:08:23 PM
As far as I know, SSO is only supported on ICN.  And just a reminder that you’re REALLLY far back on fixpacks. ;) 
Title: Re: Single sign-on for client
Post by: jsquizz on June 24, 2019, 04:58:01 AM
I am very interested in this as well.

I tried this with a client as well back in 2015, and after working with with IBM we were under the impression that we COULD do it with the thick AND admin client!
Title: Re: Single sign-on for client
Post by: wdssnyder on June 25, 2019, 12:50:54 PM
Question: Thick client - menu bar - Options - has View Combined Documents. Does ICN client perform the 'View Combined Documents' Options feature?
Title: Re: Single sign-on for client
Post by: Ed_Arnold on July 02, 2019, 12:08:30 PM
I got this from a colleague:

Quote
SSO is supported between CMOD and ICN as of 10.1.0.3 and ICN 3.0.4.

Please refer to the following document.

https://www-01.ibm.com/support/docview.wss?uid=ibm10713479 (https://www-01.ibm.com/support/docview.wss?uid=ibm10713479)

Ed
Title: Re: Single sign-on for client
Post by: rjrussel on July 05, 2019, 01:25:33 PM
The cliff notes answer is that the Windows Client does not natively support SSO. You would have to develop a custom security exit and pass some information to the arsgui.exe at startup using the /u username and /p password switches.

-RR
Title: Re: Single sign-on for client
Post by: Lars Bencze on September 20, 2019, 06:46:10 AM
We have built a "SSO ready" solution for a customer (custom arsusec exit). I write "SSO ready", since the customer has STILL not implemented a SSO solution (I think they are considering Kerberos).
If and when they do, our solution will accept a ticket as an input parameter, and this ticket will be verified vs the whatsitcalledthingamy-"ticket dispensing server" or whatnot. Today, we have a simpler algorithm in place for handling this (as they don't have any "real" tickets), and our solution works with the same number of parameters. ITs just the content today that is not real SSO.

So yes, it should be quite doable.