Has anyone been able to develop a SSO using enterprise AD/LDAP (or CAS) for TV12 using the API/REST?
"SSO" and "CAS" What you meant ?
Please expand these shortcuts.
SSO = Single Sign On
CAS = An authentification protocol commonly used (https://en.wikipedia.org/wiki/Central_Authentication_Service)
and CAS ?
As far as I know this is only to manage TV UsersAccounts with relation to LDAP/AD.
I understand that you was trying to make an commonly instaled TV APP on each AD station.
And in your case you need to make such follwowing thing happend:UserX loging to StationA using AD/LDAP account, and he should be automaticaly loged in to they own account in TV APP. ?
I understand that but I wanted to know if anyone had done it already and wanted to share his recipe to do it. We've been able to do the AD users synch into TV using the sample code here: https://integrate.teamviewer.com/en/integrate/activedirectory/index.aspx. We had to update it a tad cause it wasnt working with nested AD groups but its now working perfectly.
But now, we'd like the user created to be able to authenticate using their AD credentials instead of having to create another password into TV user management. So basically a trust in authentication between TV and our AD/LDAP.
I try to answer you, even though you probably should apply directly to the TeamViewer support.If I understand correctly, you want to run the SSO starting from authentication of your Windows client on their client TeamViewer: I think this is not possible, given that TeamViewer is an independent Service Provider for their credentials and provides a mechanism for OAuth for accessing user/groups/connections information and so on.
OAuth is the only way to access those services that offer their own authentication and authorization mechanism. (Facebook, Google, LinkedIn, Windows etc... do the same)
In any case, if TeamViewer offered a mechanism such as that required I would NOT use at all; If your business suffer an identity theft, even accounts of TeamViewer suffer the **bleep**.
The same thing would occur with roles reversed: here and I think you'd be even less happy.
It 's my opinion... of course.
Thanks DomLan for your reply!
From what I got by calling TV Support team is that the API actually allow such things as federating authentication but arent ready to put effort in documenting it and give code samples and the such but its there. They're really interrested in that feature and they already had it in their roadmap.
Thanks also for your opinion about identity thief. Im not that good in identity security and that field, but in here we're seeing more and more authentication federations between apps and 3rd parties with however enforced password and security policies, etc. But yeah, I get your concern.
I did not know that TeamViewer was moving in this direction regarding the federation between different services. But when talking about federated authentication I refer as a claims-based identity system: claims-based identity promotes separation of concerns at a level never archived before in the identity management world.
I'm covering the documentation to which you have reported in a previous post, and without going into details I would point out that in any case there is a separation that obviously concerns the credentials.In your system you can give authenticate a user with "Alfred" or "Domain\Alfred"; TeamViewer in every case will keep the uniqueness of the user referring to the email address of your users who (hopefully) is unique in the world. There are certainly many items that TeamViewer will have to pay attention.
I therefore believe that the integration bid is given to relieve the transcription of a large number of master data, especially for large reality equipped with a corporate license.In any case, without knowing exactly who will act as STS (Security Token Service) and who as RP (Relying Party), each additional answer would certainly be wrong.@MAN: Very interesting topic!!!
Hi to all,
This is TeamViewer's most recent answer.
currently it's not possible to use our REST API for authentication against an identity provider (IdP), but the good news are, that we are currently working on a Single Sign-On (SSO) solution.
In the meantime, you could test / use our feature "Identity Provider Connections" (IdPC) as additional security level for authentication against your IdP, as DomLan mentioned.
It looks like you're new here. If you want to get involved, click one of these buttons!