|
|
Subscribe / Log in / New account

Designing for failure

Designing for failure

Posted Jan 19, 2017 0:26 UTC (Thu) by josh (subscriber, #17465)
Parent article: Designing for failure

Persona had a particularly compelling use case to offer: eliminating authentication entirely, in favor of integration with browsers and Sync. The browser could do in-browser authentication locally, authenticate to sites using the Persona protocol, and sync access keys between devices. That would have entirely eliminated passwords, including for the Persona service itself.

However, that use case never quite materialized; the promised browser extensions and local integration didn't really happen. Which left Persona as a somewhat less compelling single-sign-on solution, using an account people didn't already have.

I'd have loved to see browser-integrated authentication that made passwords obsolete. I still would.


to post comments

Designing for failure

Posted Jan 19, 2017 0:33 UTC (Thu) by pabs (subscriber, #43278) [Link] (8 responses)

One already exists: client side TLS certs. Debian uses it:

https://wiki.debian.org/DebianSingleSignOn

Designing for failure

Posted Jan 19, 2017 0:53 UTC (Thu) by josh (subscriber, #17465) [Link] (3 responses)

Client certificates have far less usability, especially across multiple sites with multiple identities.

Designing for failure

Posted Jan 19, 2017 5:14 UTC (Thu) by daurnimator (guest, #92358) [Link] (2 responses)

Well can we fix that?

Designing for failure

Posted Jan 19, 2017 7:57 UTC (Thu) by pabs (subscriber, #43278) [Link]

It is more likely they will go away altogether. IIRC with Chrome you currently have to whitelist sites and they plan to reduce or delete the functionality eventually.

Designing for failure

Posted Jan 19, 2017 20:01 UTC (Thu) by josh (subscriber, #17465) [Link]

Not with client certificates, no. But I've seen a few web standards proposals floating around for browser-based challenge-response authentication.

Designing for failure

Posted Jan 19, 2017 0:53 UTC (Thu) by SEJeff (guest, #51588) [Link] (3 responses)

I'm curious if that predates the Fedora Account System, which is 100% based on TLS client certificates as well for all Fedora webservices:

https://fedorahosted.org/fas/

Designing for failure

Posted Jan 19, 2017 0:58 UTC (Thu) by pabs (subscriber, #43278) [Link]

The Debian one used to be based on DACS, the client certs part is relatively recent.

Designing for failure

Posted Jan 19, 2017 8:06 UTC (Thu) by zdzichu (subscriber, #17118) [Link]

Actually, Fedora migrated to Kerberos recently.

Designing for failure

Posted Jan 19, 2017 15:20 UTC (Thu) by smoogen (subscriber, #97) [Link]

The Fedora Account System (FAS) is a 'lot more' than just client side certs. That part was mainly for the build system, and I think that predates Persona but in a way that Fedora wasn't the inventor but trying to implement Kerberos in SSL (ie the client side certificate was analogous to the keytab. And yes this is an unfair characterization on my part.). I think that the large scale lack of adoption of Persona but just enough to keep it going was similar to what we saw with Fedora in that for every group that picked it up.. it wasn't enough to push for more development to fix things.

As pointed out by others, the Fedora Account System that Fedora proper uses has tied in various kerberos bits and so packagers no longer need to download certificates (though dozens of wiki pages still say they need to.) but do a kinit to get a kerberos ticket for the background system. This isn't the end of the old system though, there is a couple of developers led by Xavier Lamien is working on FAS3 which has other updates to I think client side certs and federation.


Copyright © 2025, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds