Jon, Succintly put. You're quite right, what I'm describing is an SSO system using OAuth.
On Dec 3, 12:07 am, Jon Crosby <[EMAIL PROTECTED]> wrote: > Andrew, > > It sounds like a single sign-on system could solve the problem you are > describing. OpenID would be used to authenticate a user and create a > session in a central location. All consumers of this information could > obtain it via OAuth (or even Basic Auth in this case because the > "user" when obtaining profile information is really just the consuming > application rather than the user when it comes to roles and access). > If you plan on exposing the profile information to other apps where > the user is in control of the exchange, then OAuth might be the right > fit. > > We implemented something like this recently at Songbird, using a > central profiles application and a plugin that was installed in all > client applications. We rolled our own but there are open source > alternatives available as well such as > RubyCAS:http://code.google.com/p/rubycas-server/. > > -Jonhttp://joncrosby.me > > On Dec 2, 3:43 pm, Andrew Betts <[EMAIL PROTECTED]> wrote: > > > Hi, > > > I'm investigating using OAuth to solve some problems in a way that I > > can't find any precedent for online, which either means I'm an > > innovator on the cutting edge of the web, completely barking mad, or > > incapable of using Google. I'm hoping someone can tell me which. > > > I work for a large organisation in which we have teams independently > > developing various different web apps that sit on a variety of > > platforms and technologies. Many of our users interact with lots of > > these systems at once. Some of them have implemented OpenID and as a > > result many of our users have OpenIDs. The problems we have are that: > > > 1. Users still have lots of passwords on various different systems > > > 2. We have copies of the same user's account data (firstname, surname, > > email etc) in many different apps > > > 3. We regularly waste time developing full-featured authentication > > layers (activation, captcha, forgotten your password etc etc) for app > > after app. > > > 4. Features developed as part of one app are sometimes taken out of > > that project and given their own app to enable those features to be > > used more widely by the business. Say for example you have a great > > asset tracking system within department A's intranet. It's identified > > as a really great piece of software and given its own host so that > > everyone can make use of it, not just department A. But now > > department A users have to log into the new app separately to their > > previously tightly-integrated intranet (even if both implement OpenID, > > because they'd each track their own sessions). > > > 5. Each app stores and manages its own permissions settings for its > > users, and this drives our department heads up the wall because they > > can't easily see what systems person A has access to and what they can > > do on each one. > > > (1) and (3) we could solve by adopting OpenID or some proprietary > > equivalent everywhere. SREG sounds like a reasonable solution for > > (2). I'm more interested in (4) and (5). If every app implements > > OpenID, you still have to log in. I can imagine the user from my > > fictional department A thinking 'didn't I do this already?' when > > presented with yet another openid signin - because they've just signed > > into a different app with the same openid, and the two apps don't > > share session state. > > > So... how about we have apps that, when faced with a user that is not > > authenticated, immediately initiate an OAuth session with a > > centralised authentication system. This may well then authenticate > > the user using OpenID, but they only do this once. So most users will > > start the day by visiting app A, be required to log in, and then visit > > apps B, C and D and use them seemingly without having to log in at > > all. Have I understood OAuth correctly in saying that this is > > possible, and am I just reinventing OpenID? Is it feasible to > > initiate OAuth without knowing who the user is yet and whether they've > > used the app before? > > > This seems to me to also solve my problem (2) better than OpenID > > alone, because part of the dataset made available to apps by the OAuth > > provider can include the user's company ID number, their department > > code, phone extension and other internal structured data. It's also a > > better solution to problem (3) because you can add it to a new app > > without needing to create any user interfaces (and therefore retrofit > > existing apps fairly easily) > > > Finally if the data that we're granting access to with OAuth is the > > user's own profile data, it could be their permissions data as well, > > so provided that the consumer app is prepared to trust the provider to > > dictate what its users can and can't do, it should be able to delegate > > permissions management to the provider and solve problem (5). > > > Result: all our users log in just once a day, there's a single master > > version of their profile data, department heads can configure a new > > hire's access to all the apps that they'll need from a single > > interface, and this glorious utopia can be achieved without our PHP > > developers having to talk to the Java guys. Question: am I barking up > > the right tree here? > > > Trust this is on topic. Apologies if not. > > > Cheers, > > > Andrew > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
