Created by Daniel Manrique on 2019-03-26 and last modified on 2019-03-27
Get this branch:
bzr branch lp:~roadmr/canonical-identity-provider/gdpr-report
Only Daniel Manrique can upload to this branch. If you are Daniel Manrique please log in for upload directions.

Branch merges

Related bugs

Related blueprints

Branch information

Daniel Manrique
Canonical SSO provider

Recent revisions

1683. By Daniel Manrique on 2019-03-27

Fix review comments

1682. By Daniel Manrique on 2019-03-26

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.

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

1680. By Daniel Manrique on 2019-01-28

Add two new substitutions to be used in SAML attribute values.

"displayname" is normally the users' Full Name in SSO.
"email" is the e-mail address.

These enable reporting richer SAML attributes to SPs who can then create nicer-looking
local identities.

Additionally, the existence of the e-mail attribute/substitution might allow
for full compliance with the SAML 8.3 "persistent" policy, though this would
require additional implementation work.

Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/saml-extra-attribute-substitutions/+merge/362265

1679. By Daniel Manrique on 2019-01-24

Actually honor SAML AuthnRequests' NameIDPolicy format.

This was done to accommodate SPs (Bomgar) which request persistent names,
indicating so in their AuthnRequest. SSO usually ignores this and always
sends "email"-policy names, which most SPs handle fine but Bomgar fails with.

The fully-correct thing to do would be to always honor the AuthnRequest and
support most/all of the SAML-specified policies, but that'd be a large effort
and risks changing semantics for other SPs, which would prevent people from
logging in, which would be bad.

Another quirk is that, while we respond saying we're giving a persistent
identifier, our identifier (the e-mail address) does NOT actually conform
to persistent semantics per SAML spec's section 8.3; we are sending the
same value (the e-mail address), just saying it's "persistent" as requested
by the SP. We do have a persistent identifier (the OpenID) but we can't send that
because then it gets sent as the username, identifier, and email address. Again,
support for this can be added to our django-saml2-idp fork but it's more work
for something that at the moment is required only by one SP.

Due do the above, in order to support Bomgar (and possibly other SPs) in a more
selective way, we only honor a non-email NameIDPolicy if:
    - the SP is configured to honor this (a boolean in the SPConfig)
    - the requested NameID policy is "persistent".

This allows us to switch this on only for very specific SPs for which we
have more control and fully understand the consequences of "lying" with our
"persistent" support.

In all other cases, we continue ignoring/overriding this and always sending
our response with "email" policy.

(As a rant, the best thing to do would be to trash our hacky SAML library
and integrate OneLogin's SAML library which is fully standards-compliant,
which is however a huge undertaking we would have to consider and prioritize)

Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/support-saml-persistent-nameid-policy-format/+merge/361982

1678. By Daniel Manrique on 2019-01-21

Add honor_authnrequest_nameidpolicy_format boolean field to SAMLConfig.

  The intended use is to enable honoring the nameid policy format requested
  by the SP's AuthnRequest, on a config-by-config basis.

  This is done because a change to fully support honoring this with
  appropriate semantics is large and likely to break existing remotes, so this
  allows a smaller change that works for specific remotes.

Merged from https://code.launchpad.net/~roadmr/canonical-identity-provider/honor-authnrequest-nameid-policy-format-field/+merge/361981

1677. By Maximiliano Bertacchini on 2019-01-15

Redirect forgot password valid POST to email-sent view regardless of whether the account exists or not.

Merged from https://code.launchpad.net/~maxiberta/canonical-identity-provider/prevent-forgot-password-user-enumeration/+merge/361166

1676. By Maximiliano Bertacchini on 2019-01-15

Pre-fill forgot password form with email value entered in the login form.

Merged from https://code.launchpad.net/~maxiberta/canonical-identity-provider/smarter-forget-password-link/+merge/361579

1675. By Tom Wardill on 2019-01-14

Remove the expiry caveat from the discharge macaroon.

Merged from https://code.launchpad.net/~twom/canonical-identity-provider/unexpiring-discharge-macaroon/+merge/359240

1674. By Maximiliano Bertacchini on 2019-01-07

Show a nice error message at user registration and reset password views when the API returns 429 - too many requests.

Merged from https://code.launchpad.net/~maxiberta/canonical-identity-provider/fix-429-crash/+merge/361148

Branch metadata

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