går vi annonceret et skridt vi tog for at øge vedtagelsen af single-sign on" på tværs af websteder på internettet. For yderligere oplysninger, kan du se dagens episode af thesocialweb.tv , der dækker starte. Mens vi meddelte, at vi ville i første omgang give begrænset adgang til vores OpenID IDP for at sikre, at det var fungerer korrekt, at vi var glade for at se, at antallet af websteder, der er registreret til at få adgang var betydeligt mere, end vi havde forventet. Så i stedet for at have vores teknikere bruge tid på manuelt at fastholde, at listen over registrerede lokaliteter, vi tager nu endnu et skridt videre og fjerne denne begrænsning, så ethvert websted kan bruge API'en.
Denne registrering kravet også ført til nogle forvirring, fordi brugerne ville være i stand til at anvende de eksisterende hjemmesider, at acceptere OpenID 2.0-kompatibel logins ved blot at indtaste "gmail.com" (eller i nogle tilfælde deres fulde E-mail-adresse) i login-felter på disse websteder. Normalt, hvad der ville ske, når brugeren har indtastet gmail.com er, at signaturmodtageren websted ville se sig om efter en speciel type fil (XRDS) om gmail.com servere, der ville kontrollere, om Gmail køre en OpenID identity provider. For gårsdagens lancering, vi specifikt har valgt ikke at offentliggøre, at særlige XRDS fil på gmail.com, fordi hvis vi havde offentliggjort den fil, brugerne ville have modtaget en fejl på Google, hvis webstedet de forsøgte at logge ind ikke var registreret hos os. Nu hvor vi har fjernet kravet om registrering, vi vil arbejde på at få at XRDS fil så hurtigt som muligt. Når XRDS fil er levende, slutbrugerne skal kunne bruge tjenesten ved at indtaste gmail.com i OpenID området for enhver loginboksen, der understøtter OpenID 2.0, svarende til, hvordan Yahoo brugere kan skrive yahoo.com eller deres Yahoo E - mail adresse. (I mellemtiden, hvis du føler virkelig nørdet, kan du skrive "https://www.google.com/accounts/o8/id" i en OpenID 2.0-kompatibel login-boksen og se den directed identity workflow in action.)
However, as we we noted in the Designing a Login User Interface section of our documentation, we do not place any requirements on the design of a federated login box on a relying party website. There are many approaches used by websites today, and the community is still experimenting with new approaches.
One other question that a lot of people asked yesterday is when a large provider like Google will become a relying party. There is one big problem that stands in the way of doing that, but fortunately it is more of a technology problem than a usability issue. That problem is that rich-client apps (desktop apps and mobile apps) are hard-coded to ask a user for their username and password. As an example, all Google rich-client apps would break if we supported federated login for our consumer users, and in fact they do break for the large number of our enterprise E-mail outsourcing customers who run their own identity provider, and for which Google is a relying party today. This problem with rich-client apps also affects other sites like Plaxo who are already relying parties.
Google is committed to working on this problem. If community members also want to help in this area, please take a look at our research on combining rich-client apps with federated login which was discussed at the recent UX summit and discussed further in a blog post here. A key thing to notice is that this research is about another open source technology called OAuth, and is agnostic to the particular federated login technology used, i.e. SAML or OpenID. It is also agnostic to the type of strong authentication method (if any) that is used to authenticate the user.
To further increase the adoption of federated login, we need standard open-source components on as many platforms as possible to enable those rich-client apps to support OAuth. That includes a lot more platforms then just Windows and Mac. The harder part is mobile devices (Blackberry, Symbian, Windows Mobile, iPhone, and yes even Android), and other Internet connected devices like Tivos, Apple TVs, Playstations, etc. that have rich-client apps that ask users for their passwords to access services like Youtube, Google photos, etc. If the community works together to build these components, they will be useful not only to Google, but also to any other relying parties that have rich-client apps or that expose APIs, and it will also help enterprise SaaS vendors like Salesforce.
If you want to help further these efforts, join the OpenID and OAuth mailing lists and tell people which platform you are targeting in case others want to help. For example, Mike Malone from Pownce did some work a few months ago to use OAuth on an iPhone and described how he got it working. And just yesterday another member of the open source community, Sean Sullivan, built a working OAuth enabled rich-client app for Android and posted the open source code.
Ingen kommentarer:
Send en kommentar