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/. -Jon http://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 -~----------~----~----~----~------~----~------~--~---
