Applications can't easily map an SSO account to a Launchpad one
Affects | Status | Importance | Assigned to | Milestone | |
---|---|---|---|---|---|
Launchpad itself |
Fix Released
|
High
|
William Grant |
Bug Description
Applications relying on SSO for authentication and Launchpad data for authorization need a way to reliably map from an SSO account to a Launchpad person.
The most correct way to do this right now is to look at the Launchpad username returned in SSO's OpenID sreg response, but access to this information is restricted and we'd like to eventually deprecate SSO's transmission of it. Some consumers have come up with more creative ways, including scraping the user's primary identifier from the delegation information on Person:+index and hoping that they use that identifier to authenticate.
We can solve this once and for all by adding a public Launchpad API method to look up a person by OpenID identifier. We already have an internal one and one for xmlrpc-private.
Related branches
- Benji York (community): Approve (code)
-
Diff: 367 lines (+179/-72)7 files modifiedlib/lp/registry/browser/tests/test_person_webservice.py (+89/-0)
lib/lp/registry/interfaces/person.py (+14/-1)
lib/lp/registry/model/person.py (+25/-0)
lib/lp/registry/stories/webservice/xx-people.txt (+0/-71)
lib/lp/registry/tests/test_personset.py (+34/-0)
lib/lp/testing/__init__.py (+3/-0)
lib/lp/testing/_login.py (+14/-0)
tags: | added: api easy openid |
tags: |
added: qa-ok removed: qa-needstesting |
So, checklist of things we need to consider:
- private people? doesn't exist
- private teams ? should never have an openid - but can we check that that is so constrained?
- privacy of openids - they are not meant to be guessable, so not a problem
This can run anonymously, I think.