Ticket #10687 (closed PLIP: wontfix)
Plone OpenID Federated Login
Reported by: | cwarner | Owned by: | |
---|---|---|---|
Priority: | minor | Milestone: | 4.3 |
Component: | OpenID support | Version: | |
Keywords: | openid login | Cc: | plip-advisories@…, davisagli |
Description (last modified by davisagli) (diff)
Proposer: Christopher Warner
Seconder: David Glick
Motivation
This is more of a usability cleanup and support for federated login. Which for all intents and purposes is OpenID by the bigger providers. This started as an easier way to get people using such services as their main net id. The problem is that the user audience isn't fully technically adept in understanding OpenID. Even to the extent that we expect users to understand and read directions the gap between such an assumption and the goal of having them sign in is few and far between. So instead, we simply assist them in signing in via one of the main OpenID providers as naturally as possible. Satisfying the need of the site administrator and the user.
Assumptions
- Site administrator wants users to sign in using OpenID
- Users generally would rather sign in using Google/Yahoo/Flickr or some such but each of these services provide OpenID
- Users don't understand a URL as being an ID. They have been conditioned to enter a username/email and password.
Proposal & Implementation
Extending of plone.openid and plone.app.openid are required to see this through to realization. The goal will be to simply allow new options for Federated login. I currently don't forsee having to go higher up the chain. In current implementation this hasn't been necessary.
Deliverables
The obvious extension of plone.openid and plone.app.openid including documentation describing the new process. Possibly a step-by-step walkthrough of options and validation of each major federated provider. This will obviously include localization of any new strings introduced.
Risks
We risk confused users but as this is an exercise in making things slightly easier for them it's a valid risk and I forsee no incompatibilities as no major underlying functional changes will be occuring.
Participants
Christopher Warner - cwarner (irc.freenode.net)
Progress
There are prototypes of a working implementation available at:
http://github.com/christophwarner/plone.openid
http://github.com/christophwarner/plone.app.openid
With a recorded example available for viewing here: http://bit.ly/dgB4M7
Commentary
I'd like to state that this is different than plonesocial.auth.rpx in that it doesn't require an api key or rely on an external service. It also doesn't link the virtual user to a local Plone account and leaves the login as it would have been a simple OpenID url in the first place.
Change History
comment:3 Changed 6 years ago by davisagli
- Priority changed from n/a to minor
- Keywords openid login added
- Description modified (diff)
- Owner davisagli deleted
Adding my name as a "seconder," but removing it as owner because I won't have time to see this implementation through. I'd be happy to help coach you through the process, though, Christopher.
comment:4 Changed 6 years ago by cwarner
Sure, sounds good to me. Let me know next steps and I'll get it done.
comment:5 Changed 6 years ago by davisagli
You're well ahead of schedule since you already have an implementation, and the first round of reviews is for the proposal only.
Next steps:
- E-mail framework-team@… to officially submit the PLIP.
- Get access to Plone svn if you don't have it already, create your branches there, and add a .cfg for the plip at https://svn.plone.org/svn/plone/buildouts/plone-coredev/branches/4.0/plips (this is to aid the review process).
comment:6 Changed 6 years ago by hannosch
Watching "2010 Google Faculty Summit: Defeating the Password Anti-Pattern with Open Standards" ( http://www.youtube.com/watch?v=IKMKAa3pgwo&playnext=1&videos=WSHd-m8KhJg) it seems the UI proposal you are suggesting here is also known as the "Nascar" problem and considered an insufficient and suboptimal approach. It clearly doesn't scale to more than a few providers.
I think adopting this over the current state of entering a string is an improvement, but we should be conscious about this being just an evolutionary step. There's still a lot of movement in the OpenID and OAuth standards and it's not clear yet where this is all headed.
comment:7 Changed 6 years ago by esteele
Your PLIP has been accepted for consideration for Plone 4.1.
Framework Team voting on this PLIP was: Alec +1 Craig +1 Elizabeth +1 Laurence +1 Martijn +1 Matthew +1 Rob +1 Ross --
The initial implementation deadline for your PLIP is October 1st, 2010. The Framework Team would certainly appreciate you finishing beforehand so that they may begin evaluating it as soon as possible. Announce its readiness here once your implementation is ready for review.
comment:10 Changed 5 years ago by rossp
- Status changed from new to closed
- Resolution set to wontfix
PLEASE READ THIS AND RE-OPEN VALID PLIPS!
As we launch the new PLIP process we'd like to see which PLIPs:
- are still appropriate/needed
- still have owners/proposers/champions
- still have available implementers
If this PLIP should still be considered for future releases of Plone please do re-open this ticket and assign an appropriate milestone. If it should be considered for the next release of Plone, use the 4.2 milestone. Also be sure to update the PLIP description, requester, owner, etc. and include a comment detailing recent progress and new plans. We will use all these details in the new continuous PLIP process.
comment:11 Changed 5 years ago by cwarner
- Status changed from closed to reopened
- Resolution wontfix deleted
comment:12 follow-up: ↓ 13 Changed 5 years ago by cwarner
Reopened ticket, progress continues there are no new plans sans the last email sent on the topic:
This initial implementation was always going to be a stop-gap measure but a couple of new things have come to light here which are changing this PLIP's functionality. The openid whitelisting patch, a UI review and some other things. Even though the minor implementation could technically make Plone 4.1 I am not sure now if it should.
After thinking about the problem a little bit more it became obvious that even though I consider the direction to be the right one. There may need to be a bigger overall push here in regards to actually solving the Nascar Problem as pointed out in the ticket and at Google's Faculty Summit. How I believe we go about doing this needs to be implemented, written up and presented to the Plone & Openid communities for review. That aside, I'd really like to wrap up the whitelisting functionality that Kai Lautaportti has been working on at the very least as it's integral to the functionality of the whole Single-Sign on Federated process which increases the functionality of the ticket but clearly for good purpose.
comment:13 in reply to: ↑ 12 Changed 5 years ago by eleddy
Christopher - the FWT wants to approve and integrate this but we are nervous about what still needs to be done exactly. If you could be more explicit about what still needs to be done, the risks, and the plan of attack on this it would help us a lot.
comment:14 follow-up: ↓ 16 Changed 5 years ago by cwarner
Sure, so after implementing a prototype of this and applying it into a semi-production scenario it turns out that there are a lot of problems via user interface and interaction issues. Especially in regards to users who are aware of their openid and then trying to use the automatic login. In those cases the generated identifier changes in response but it is actually the same account. So automatic association needs to be done there. I'm in the process of rolling out a more robust prototype at nyu where I hope to get more information and can sure some of those issues up.
There are also user management issues that I simply haven't worked out yet. For instance, managing the user becomes problematic as some users are using one openid and simply decide they are changing it on a whim. So instead of Yahoo, they switch to Google. This in and of itself isn't a software issue perse but being able to manage the process or migrating the user and the content they've created is another slightly messy issue.
There are also other minor issues in to making sure the discovery endpoint uri is configurable. Walking through and making sure each of the main openid endpoints behaves the same way to the user and more.
My time here at NYU will most likely revolve back to this in the next couple of weeks so I'd like to simply leave the ticket open as on-going and at the very least update with relevant doc and source. There is a paper i'm writing with this that simply isn't complete and it's not an easy problem. However nailing down a proper implementation that is usable for all services, including user configurable endpoints will take more time.
If the FWT sees it fit this not make Plone at all that is one thing, but I think having a robust and usable solution instead of a confusing mess will be highly beneficial. I'm of the mentality that this need not be a PLIP if it is causing confusion or holding anything up and I can continue my work here and when it's ready it will again be considered for inclusion. It is simply not as easy as originally anticipated.
comment:16 in reply to: ↑ 14 Changed 5 years ago by eleddy
- Milestone changed from Future to 4.2
Replying to cwarner:
Thanks for the update. The FWT would like to see this happen so I'm going to put a 4.2 release marker on it and let's just go for broke on hitting it. In the meanwhile, it sounds like you need some people to throw ideas off of. I am happy to look at some of the front end issues, or just to talk about them. I'm not entirely too familiar with the insides though so I don't feel comfortable talking about implementation. Seeing that davisagli was a seconder I put him on the cc and maybe he can help if needed there :)
Happy to keep this as a PLIP, we just want to see it go in a fixed direction and will try to get you what help you need. Based on the previous comments it just seems like there is a direction that needs to be chosen. Let me know what I can do to help here (either on this ticket or email is fine).
comment:17 follow-up: ↓ 18 Changed 5 years ago by cwarner
Not only, but definitely need to do testing which is the main concern here and will update shortly. I've found over the course of testing in two different places with just minor changes that a large part of the problem is still social.
I'm hoping to have a public demo available within the next couple of weeks.
comment:18 in reply to: ↑ 17 ; follow-up: ↓ 19 Changed 5 years ago by eleddy
Replying to cwarner:
Not only, but definitely need to do testing which is the main concern here and will update shortly. I've found over the course of testing in two different places with just minor changes that a large part of the problem is still social.
I'm hoping to have a public demo available within the next couple of weeks.
Any movement here? I'm happy to help out with testing.
comment:19 in reply to: ↑ 18 Changed 5 years ago by cwarner
Replying to eleddy:
Replying to cwarner:
Not only, but definitely need to do testing which is the main concern here and will update shortly. I've found over the course of testing in two different places with just minor changes that a large part of the problem is still social.
I'm hoping to have a public demo available within the next couple of weeks.
Any movement here? I'm happy to help out with testing.
No, still inching forward, please don't close.. I'm not going to have time to move this forward for at least another two weeks. I'm balancing a couple of other different projects but the Plone community has my word I will come around on this and my word is worth at least an average weight 68 kilos.
comment:20 follow-up: ↓ 23 Changed 5 years ago by cwarner
In gold that is..
comment:21 Changed 5 years ago by eleddy
Don't worry we won't close it - just bump it to the next release :) I still want to get this into 4.2 and we have a feature freeze on June 30th. What would you say to having one FWT member (likely myself) review this plip as it is and find out where we are? I assume there is a TODO list somewhere as well and we can review knowing that is there. Thoughts?
comment:23 in reply to: ↑ 20 Changed 5 years ago by eleddy
Just checking in again. The new process means we can review at any time. Would love to wrap this up soon.
comment:24 Changed 5 years ago by rossp
The FWT has wrapped up work on 4.2 and can start work on 4.3 whenever we have PLIPs to review. So can you as proposers or implementers please check in on your PLIPs and let us know what the status is and when we can expect issues to be addressed and implementations complete so we can review them for merge in 4.3.
comment:25 Changed 5 years ago by eleddy
Just curious what is up with this Plip. Is there any intent to finish this for the 4.3 release?
comment:26 Changed 4 years ago by eleddy
- Status changed from reopened to closed
- Resolution set to wontfix
Due to lack of response and missing several deadlines I am going to close this PLIP. If you have time to re-pick it up, please resubmit for the review process with a clear direction forward. THanks!
comment:27 Changed 4 years ago by cwarner
I'd like to leave this ticket closed but leave some commentary as I have some time to backtrack here and talk about this sensibly. Working on this implementation has led to several findings that I will leave here in case anyone thinks about doing this again. To be short, you should never do this. The implementation works but it's not recommended. There are several problems with OpenID all around I have found in regards to usability and management that would cause more problems than it is worth. Making it easier to use the OpenID is not the problem, but its with OpenID itself. Infact sadly, my opinions of OpenID have changed from something that is useful to something that in practice is tragically flawed. In this case specifically both for Plone users and administrators.
- The use case scenario as outlined in the video works up and until you need to do anything with user management. For instance, some of the ID's for openid cause problems with userid management and URI conversion.
- There are issues with management of multiple ids or renaming ids for users and updating their associated content. For instance, a user will use one openid and immediately decide that they will use another openid to create content. Either because they don't like their URI display or they just feel like it (this can be managed via user configlet and oauth 2 but realistically people aren't managing that data properly on the endpoint side or they end up wanting to change it). Managing and changing the owners of this content becomes an issue for the administrator.
- These major OpenID endpoints just don't seem to be stable for whatever reason and also operate differently. For instance the AOL endpoint operates differently than the Google endpoint. This isn't such a big deal except that in actual practice i've had users create an OpenID with one service and because an endpoint was down immediately create a different OpenID. Again, management issues here.
- It seems a large portion of patron can't remember what their OpenID actually is.
There are many more issues involved with it that I can't remember off the top of my head which is why this should never be put into Plone core and should be rejected in the future.
These are more user-end problems but if anyone does want to pick this up, feel free to contact me or post to this ticket.