Created by Danny Tamez on 2010-04-21 and last modified on 2019-05-22
Get this branch:
bzr branch lp:canonical-identity-provider
Members of Ubuntu One PQM Team can upload to this branch. Log in for directions.

Branch merges

Related bugs

Related blueprints

Branch information

Ubuntu One PQM Team
Canonical SSO provider
Review team:
Ubuntu One hackers

Recent revisions

1689. By Daniel Manrique on 2019-05-10

Show friendly help if we can't find the openid session token from a validation link

The most common reason for that is initiating a login on a third-party site,
creating the account in sso as part of the flow, then clicking on the
activation link on another device or browser.

SO instead of sending people to a terse 404 page which causes them to fume and
come file bugs which end up as dupes of https://pad.lv/1693375, the new (still
a 404-code) page explains what to do and provides a link where they can
validate their e-mail address out of the third-party login flow (which is the
workaround we recommend anyway, after painful back and forth checking the
format of the link they clicked on and referring to the cited bug)

Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/better-evil-token-instructions/+merge/367285

1687. By Po-Hsu Lin on 2019-05-08

Enable the zh-tw language support for Ubuntu One web UI.

Merged from https://code.launchpad.net/~cypressyew/canonical-identity-provider/canonical-identity-provider/+merge/366307

1686. By Celso Providelo on 2019-04-12

New privileged API for checking username availability.

Merged from https://code.launchpad.net/~cprov/canonical-identity-provider/usernames-api/+merge/365688

1685. By Daniel Manrique on 2019-04-10

SAML: Ensure all dicts used to build assertions contain only utf-8-encoded data.

The SAML library we use assumes use only of ascii inputs and parameters and Python 2 str <-> unicode implicit conversion intricacies. Some of those assumptions are broken by SSO's use of the library and particularly the CanonicalProcessor, which gets a lot of those assertion parameters and attributes from the database; SP config parameters, custom attributes come from Django ORM and are thus unicode, and since the SAML library doesn't do explicit unicode data encoding, it barfs when implicit conversions for unicode data that contains non-ascii characters are attempted, particularly when using the python string.Template classes and base64-encoding the final assertion;these behave predictably badly when given a str template and fed unicode substitution values.

Since the output is expected to be utf8-encoded XML, this MP just ensures all the pieces used by the library to assemble, sign and encode the assertion are sent as utf8-encoded strs rather than unicodes.

This problem was only exposed when we added a new "full name" substitution for SAML attributes: up until now, by some fluke, all the date we fed to the SAML library was ascii-only and so even when we were sending mixed strs and unicodes back and forth, implicit conversion of unicode to str worked fine and the problem went undetected. However, fullnames, unlike URLs and other identifiers, usernames and OpenIDs, understandably can contain non-ascii characters.

Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/saml-unicode/+merge/365615

1683. By Celso Providelo on 2019-04-08

Stop accepting usernames with DOTs and PLUSes.

Merged from https://code.launchpad.net/~cprov/canonical-identity-provider/cleaner-usernames/+merge/365370

1682. By Daniel Manrique on 2019-03-27

    Add GDPR report admin action for accounts.

    The intent is to have a read-only, copy-pasteable view for GDPR requests.
    Currently the information to be reported is scattered between the Account
    change form and the auth logs changelist. The Account form contains most of the
    relevant data but since it's a form, it can't be cleanly copy-pasted.

    If more GDPR-relevant information is required, this view can easily be expanded
    to present that as well.

Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/gdpr-report/+merge/365134

1681. By Daniel Manrique on 2019-03-06

Do not store/use an OATH TOTP client's calculated "absolute drift".

Per LP bug #1817075, the "stored absolute drift" functionality of python-oath
is broken and allows a client to reuse a token that is just expired (due to
allowing relative drift of +/-30 seconds), and keep reusing it just past the
end of the previously-calculated absolute drift to keep it "alive"

A side-effect of this is that we will require OATH TOTP devices to have
*accurate* clocks, which is deemed acceptable since the vast majority of clients
are either phones or computers. "Accurate" is quite lenient though, because
a device can be +/- 45 seconds off and still generate valid codes.

Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/non-drifting-totp/+merge/363558

Branch metadata

Branch format:
Branch format 7
Repository format:
Bazaar repository format 2a (needs bzr 1.16 or later)
This branch contains Public information 
Everyone can see this information.