<html><head></head><body><div>Peter,</div><div><br></div><div>I completely agree. Writing down passwords anywhere is a bad idea, but I think the benefits greatly outweigh the risks in this case:</div><div><span><br></span></div><div>* How is this URI to be used?</div><div>- The user logs onto a secure web site controlled by the XMPP server operator ("service provider", SP). Logging in with the SSO mechanism requires the user to authenticate against his identity provider (IDP); how this happens is defined entirely by the identity provider and beyond the scope of this writeup.</div><div>- On this web site, the user already has some ability to interact with the XMPP server. This may include a web chat or other mechanisms, which are not of relevance here.</div><div>- One of the interactions is that the user creates a device and service specific password, i.e. a password which is only to be used with an XMPP client application to be run on the device the web browser runs on.</div><div>- The traditional approach would be to memorize or copy/paste this password to the XMPP client on this device. This is both cumbersome and a possible information leak (the clipboard can be read system-wide by any application, it may be later pasted erroneously into a wrong field, …; you get the idea). This can be used for applications not supporting the "add account" function.</div><div>- The proposed approach would be to (also) have the xmpp:…?addaccount… URI, e.g. in a button "add this account to your XMPP client". Then the user would only need to click on this, and things would go almost as easy as for "integrated" proprietary IM solutions.</div><div><br></div><div>* Security implications</div><div>a) This URI would (a) be securely transmitted over HTTPS, between parties which already have more power than the password will enable them to wield (XMPP server, web browser with SSO login knowledge).</div><div>b) It would only be available to (1) the web browser which already has performed the initial SSO, so no security risk there and (2) sent to the XMPP client, which will need access to the password anyway.</div><div>c) It is *not* sent to anyone else, and the password is not usable for anything else (not for SSO nor for any other service).</div><div>d) It will not be the password a user choses and might be stored on a post-it on the screen or below the keyboard; it is not a password reused from a third-party service vulnerable to password theft. </div><div><br></div><div>The overall goal is to make the activation and setup of a mobile or desktop application almost as simple as for proprietary IM clients while easily enabling SSO mechanisms for clients and avoiding several of the mistakes that generally happen with passwords.</div><div><br></div><div>So while the password is exposed, it really is exposed less than with alternatives, and also the SP does not need to know or store any valuable password.</div><div><br></div><div>Agreee?</div><div><span>-- <div><a href="https://me.uni.kn/marcel.waldvogel">-Marcel</a></div></span></div><div><br></div><div>On Do, 2016-11-03 at 12:17 -0600, Peter Saint-Andre wrote:</div><blockquote type="cite"><pre>On 11/3/16 9:04 AM, Marcel Waldvogel wrote:
<blockquote type="cite">
Hi,
we're looking into using XMPP together with (passwordless) single sign
on mechanisms such as Shibboleth (SAML).
As most (all?) clients only support password authentication, this cannot
be used directly. Implementing Shibboleth is also not trivial, so it is
unlikely we can convince a large portion of the developers to do so.
We are therefore looking into creating per-application passwords on a
web page. To make this easy, it would be nice if applications were to
supported a URI like xmpp:<a href="mailto:romeo@montague.net">romeo@montague.net</a>?addaccount;password=Jul13t
<<a href="file://romeo@montague.net?addaccount;password=Jul13t">file://romeo@montague.net?addaccount;password=Jul13t</a>>, as an extension
to XEP-0147.
This would be much easier to implement and would — for the user — make
adding an account almost as simple as native SSO support.
What do you think?
</blockquote>
Putting passwords in URLs is a bad idea. :-)
Peter
_______________________________________________
JDev mailing list
Info: <a href="https://mail.jabber.org/mailman/listinfo/jdev">https://mail.jabber.org/mailman/listinfo/jdev</a>
Unsubscribe: <a href="mailto:JDev-unsubscribe@jabber.org">JDev-unsubscribe@jabber.org</a>
_______________________________________________
</pre></blockquote></body></html>