Skip to content
Snippets Groups Projects
  1. Oct 03, 2022
    • Jakub Darmach's avatar
      Keystone OIDC JWKS fix · 98929761
      Jakub Darmach authored
      JWT failed to validate on auth-oidc endpoint used by openstack cli
      with "could not find key with kid: XX" error. To fix this we need
      to use jwks provided in "jwks_uri" by OIDC metadata endpoint.
      
      Missing "ServerName" directive from vhost config causes redirection
      to fail in some cases when external tls is enabled.
      
        - added "keystone_federation_oidc_jwks_uri" variable
        - added "OIDCOAuthVerifyJwksUri" to keystone vhost config
        - added "ServerName" to keystone vhost config
        - jinja templating additional whitespace trimmed to
          correct end result indentation and empty newlines
      
      Closes-bug: 1990375
      Change-Id: I4f5c1bd8be8e23cf6299ca4bdfd79e9d98c9a9eb
      Unverified
      98929761
  2. May 17, 2022
  3. Jan 31, 2022
  4. Jan 09, 2022
    • Stig Telfer's avatar
      OpenID Connect certifiate file is optional · 78f29fdc
      Stig Telfer authored
      Some ID provider configurations do not require a certificate file.
      Change the logic to allow this, and update documentation accordingly.
      
      Change-Id: I2c34a6b5894402bbebeb3fb96768789bc3c7fe84
      78f29fdc
  5. Feb 15, 2021
    • Pedro Henrique's avatar
      Add support to OpenID Connect Authentication flow · f3fbe837
      Pedro Henrique authored
      
      This pull request adds support for the OpenID Connect authentication
      flow in Keystone and enables both ID and access token authentication
      flows. The ID token configuration is designed to allow users to
      authenticate via Horizon using an identity federation; whereas the
      Access token is used to allow users to authenticate in the OpenStack CLI
      using a federated user.
      
      Without this PR, if one wants to configure OpenStack to use identity
      federation, he/she needs to do a lot of configurations in the keystone,
      Horizon, and register quite a good number of different parameters using
      the CLI such as mappings, identity providers, federated protocols, and
      so on. Therefore, with this PR, we propose a method for operators to
      introduce/present the IdP's metadata to Kolla-ansible, and based on the
      presented metadata, Kolla-ansible takes care of all of the
      configurations to prepare OpenStack to work in a federated environment.
      
      Implements: blueprint add-openid-support
      Co-Authored-By: default avatarJason Anderson <jasonanderson@uchicago.edu>
      Change-Id: I0203a3470d7f8f2a54d5e126d947f540d93b8210
      f3fbe837
  6. Aug 06, 2020
  7. Feb 11, 2020
  8. Jun 17, 2019
  9. May 17, 2019
    • Mark Goddard's avatar
      Fix keystone fernet key rotation scheduling · 6c1442c3
      Mark Goddard authored
      Right now every controller rotates fernet keys. This is nice because
      should any controller die, we know the remaining ones will rotate the
      keys. However, we are currently over-rotating the keys.
      
      When we over rotate keys, we get logs like this:
      
       This is not a recognized Fernet token <token> TokenNotFound
      
      Most clients can recover and get a new token, but some clients (like
      Nova passing tokens to other services) can't do that because it doesn't
      have the password to regenerate a new token.
      
      With three controllers, in crontab in keystone-fernet we see the once a day
      correctly staggered across the three controllers:
      
      ssh ctrl1 sudo cat /etc/kolla/keystone-fernet/crontab
      0 0 * * * /usr/bin/fernet-rotate.sh
      ssh ctrl2 sudo cat /etc/kolla/keystone-fernet/crontab
      0 8 * * * /usr/bin/fernet-rotate.sh
      ssh ctrl3 sudo cat /etc/kolla/keystone-fernet/crontab
      0 16 * * * /usr/bin/fernet-rotate.sh
      
      Currently with three controllers we have this keystone config:
      
      [token]
      expiration = 86400 (although, keystone default is one hour)
      allow_expired_window = 172800 (this is the keystone default)
      
      [fernet_tokens]
      max_active_keys = 4
      
      Currently, kolla-ansible configures key rotation according to the following:
      
         rotation_interval = token_expiration / num_hosts
      
      This means we rotate keys more quickly the more hosts we have, which doesn't
      make much sense.
      
      Keystone docs state:
      
         max_active_keys =
           ((token_expiration + allow_expired_window) / rotation_interval) + 2
      
      For details see:
      https://docs.openstack.org/keystone/stein/admin/fernet-token-faq.html
      
      Rotation is based on pushing out a staging key, so should any server
      start using that key, other servers will consider that valid. Then each
      server in turn starts using the staging key, each in term demoting the
      existing primary key to a secondary key. Eventually you prune the
      secondary keys when there is no token in the wild that would need to be
      decrypted using that key. So this all makes sense.
      
      This change adds new variables for fernet_token_allow_expired_window and
      fernet_key_rotation_interval, so that we can correctly calculate the
      correct number of active keys. We now set the default rotation interval
      so as to minimise the number of active keys to 3 - one primary, one
      secondary, one buffer.
      
      This change also fixes the fernet cron job generator, which was broken
      in the following cases:
      
      * requesting an interval of more than 1 day resulted in no jobs
      * requesting an interval of more than 60 minutes, unless an exact
        multiple of 60 minutes, resulted in no jobs
      
      It should now be possible to request any interval up to a week divided
      by the number of hosts.
      
      Change-Id: I10c82dc5f83653beb60ddb86d558c5602153341a
      Closes-Bug: #1809469
      6c1442c3
  10. Nov 23, 2018
Loading