lp://staging/~deadlight/canonical-identity-provider/vanilla-templates

Branch merges

Propose for merging

No branches dependent on this one.

Related source package recipes

No recipes using this branch. (?)

Create packaging recipe

Related snap packages

Related bugs

Related blueprints

1687. By Karl Williams on 2019-07-16

Add short path for vanilla and remove unused css

1686. By Karl Williams on 2019-07-16

Revert to pre-vanilla

1685. By Karl Williams on 2019-07-16

Add node modules directory to the includes path for sass

1684. By Karl Williams on 2019-07-15

Merge from master

1683. By Karl Williams on 2019-07-15

Update gulpfile, add vanilla framework as a dependency and add some initial vanilla config and sass

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"
indefinitely.

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