Fixes #25809 - JWT auth for external users by rabajaj0509 · Pull Request #6549 · theforeman/foreman

rabajaj0509 · 2019-03-07T14:21:19Z

This pr enables Foreman to act as a consumer of the JWT token. It makes sure that an external user, authenticated via a third party application(in my case keycloak), can be created using the JWT token(without the need of a password).

theforeman-bot · 2019-03-07T14:21:32Z

Issues: #25809

timogoebel

@rahulbajaj0509: I checked out the code. I still believe you should not hook into the SSO::JWT workflow as this is unrelated to what you want to achieve. It both uses JWTs, that's the only similarity.
You do need money to buy a tree or a space station. But both a tree and a space station are totally unrelated. The JWT is just the technique used to transfer payload. I'd suggest to create a separate SSO implementation for Open Id Connect and try to use a gem that offers a proper implementation.

timogoebel · 2019-03-12T19:31:11Z

      session[:user] = user.id
      session[:api_authenticated_session] = true
+      if jwt_data[:sso_method] == "SSO::Jwt"
+        add_jwt_sesssion_values(jwt_data)


How about session.merge!(jwt_data)

Doesn't this store data in the session that was read from the session a couple of lines before? 😕

It should have, but since we have the reset_session on line no.79, it resets all the values and therefore I had to use this method to restore the value again.

timogoebel · 2019-03-12T19:36:36Z

  def set_activity_time
-    session[:expires_at] = Setting[:idle_timeout].minutes.from_now.to_i
+    unless session[:sso_method] == 'SSO::Jwt'
+      session[:expires_at] = Setting[:idle_timeout].minutes.from_now.to_i


Can we ask the SSO if it sets the expiry time instead of hardcoding stuff for JWT here?

def set_activity_time return if available_sso.sets_expiry_time? session[:expires_at] = Setting[:idle_timeout].minutes.from_now.to_i end

Yes, I think I can achieve this, thanks!

@timogoebel I tried using available_sso.sets_expiry_time?.
It works fine when we first authenticate the user.
However, when we use sessions in subsequent calls the method fails.

That is if I run hammer auth login basic --username admin --password changeme it works correctly.
Immediately after when I run hammer os list (which will use session since we are already autheticated in the previous command), it fails because all the SSO methods (Basic, JWT, openIDConnect etc) return a false for {SSO::Method}.available?..

Hence we get available_sso value as nil when using session

You should be able to use get_sso_method to get the SSO object stored in the session.

rabajaj0509 · 2019-03-13T13:28:39Z

@timogoebel let me explain a bit about what I am trying to achieve here, let me know if I am thinking in the correct direction here.

So at the hammer-cli-foreman side, I authenticate the user by keycloak using the OAuth out of bound implementation. In return to that, the Keycloak returns me with a JWT that has the authenticated users authorization information which I send to Foreman(here) and create a user in Foreman using that JWT.

This is the flow that I am trying to achieve.

ares

@rahulbajaj0509 could you please point us to respective part that actually issues the JWT token? I'm a bit confused here about the whole flow. I suppose something creates the JWT which is added to requests to Foreman. If that's the case, we download the public key from some URL and decode the token (which does the token signature verification) and then read information out of that token.

ares · 2019-03-18T07:28:22Z

+
+  def generate_jwks_uri
+    response = RestClient::Request.execute(
+      :url => "https://ssoo1.usersys.redhat.com/auth/realms/hammer-cli/protocol/openid-connect/certs",


what is this url? it does not resolve, IIUC we download the keycloak public key from here and then use it for signature verification, should this URL be part of JWT token?

I have added this to the settings, this URL is different for each user, so it may differ. To obtain the URL user can read the description of the field as seen here

ares · 2019-03-18T07:29:53Z

+      :url => "https://ssoo1.usersys.redhat.com/auth/realms/hammer-cli/protocol/openid-connect/certs",
+      :method => :get,
+      :headers => { content_type: 'application/x-www-form-urlencoded'},
+      :verify_ssl => false


this is not a good idea, we need to trust the side that provides the public key, otherwise an attacker could give us wrong public key for verification

@ares thanks, makes sense, I have change the setting to :verify_ssl to true.

ares · 2019-03-18T07:33:39Z

+    key.set_key(base64_to_long(modulus), base64_to_long(exponent), nil)
+  end
+
+  def base64_to_long(data)


was this code taken from some library? if not, can you describe what's going on in here, e.g. what format we're trying to build here, we don't use unpack('C*') every day :-)

yes, it was but as @tbrisker mentioned, it is not good to handle the encryption by ourself, so I am using the JWT gem to do all this for us.

ares · 2019-03-18T07:36:32Z

+  end
+
+  def to_hex(int)
+    int < 16 ? '0' + int.to_s(16) : int.to_s(16)


1.to_s(16).rjust(2, '0') is more straightforward

ares · 2019-03-18T09:19:10Z

-    return nil if secret.blank?
-
-    payload = JWT.decode(token, secret.token)
+    if secret.blank?


is there a better way to detect what type of token this is? Can we get that information out of decoded_payload?

We should never rely on information in decoded_payload as it hasn't been verified (the signature wasn't validated).

We verify the signature later, but we need to decide what is the purpose of this token here. We can decode and if that's for SSO, we proceed with verification. If it's not and we just decode like we did before.

I don't like this too much, hence I'm asking for a better way of differentiation. Is it possible to use other header or that breaks jwt conventions? Can we somehow detect the signature is present, meaning this is SSO token? If we detect there's signature, then perform verification (which JWT.decode does for us if we pass public key I believe)

We can use the Auth-Header. The RFC states to use two parts:
TYPE SECRET. The type can be an arbitrary string, e.g. Basic. I would suggest using Bearer for OIDC and JWT for JWT's issued by Foreman.

rabajaj0509 · 2019-03-18T10:22:57Z

@ares thanks for reviewing the pull request :)

We receive the token from the hammer-cli-foreman which can be seen here.

Hammer uses the rest-client gem to authenticate the user from Keycloak and if the authentication is successful it receives a JWT token in return. Now we send this JWT here in Foreman and then create a user with external login.

When we send the JWT token in Foreman, we need to validate it and make sure it the same token as we had sent from Hammer.

There are two ways of validating a JWT token on the foreman side:

Method 1: We need to verify a few claims and check the signature:

The important bits to check in the token:
- typ - should be Bearer
- aud - should include the client_id of the service
- nbf - should be in the past (check against current time - 1 sec)
- exp - should be in the future (check against current time + 1 sec)
For this, I am using the JWT gem that basically does all the checks
when we do JWT.decode with the token that we receive from Hammer and public key that we generate using the generate_key_from_jwks method.

Method 2: we can also invoke the token introspection endpoint on Keycloak, but that's then a remote call to Keycloak to validate the token.

Basically, this can be done by invoking the introspection endpoint with the token. In return, we will recieve a valid and JSON of the token that can be future matched/validated with our token.

rabajaj0509 · 2019-10-03T06:15:44Z

@tbrisker @timogoebel initially I thought it might be something inside jwt gem that loops/waits/sleeps for a long time under certain conditions but i was wrong. I made a blunder with a condition and failing of the tests justified it! Although now the tests are finally green 👍

tbrisker

Do you have any idea when a new version of JWT will be released with the fix? iiuc right now this doesn't work on ruby 2.3, i'd be fine with that as an initial step but if we won't be able to fix that in the near future we'll need to have some other way of handling it (such as carrying a patched gem or using the github version)

tbrisker · 2019-10-03T07:07:11Z

+  end
+
+  def valid_jwt?
+    return false if Setting['oidc_algorithm'].nil? || !OpenSSL::PKey::RSA.new.respond_to?(:set_key)


Does this mean jwt auth won't work with ruby 2.3, or at least until jwt releases a new version? should the condition be more explicit so we know when we can remove it?

Yes, I have done the fix here: jwt/ruby-jwt#333. The gem releases every 3 months but this time they have identified few issues with the gem therefore they might do the release in few weeks.

Also, I have an eye on the gem as I am working on few issues of the gem. Once, we have the new version of the gem, then I will update this condition.

What do you think?

@tbrisker to be safe I have added a comment that addresses our concern. Does that make sense?

I would prefer to raise or at least log an error instead of failing silently in this case - otherwise users have no way of telling why this failed.

tbrisker · 2019-10-03T12:17:08Z

+    test 'if valid jwk json is passed' do
+      stub_request(:get, Setting['oidc_jwks_url'])
+        .to_return(body: {"keys": [@jwk.export]}.to_json)
+      if OpenSSL::PKey::RSA.new.respond_to?(:set_key)


IIUC this essentially makes all of these tests do nothing other than setup. Why not use skip instead? or wrap the whole context in a condition?

rabajaj0509

@tbrisker I have worked on your comments - re factored test cases in oidc_jwt_token_validate_test.rb by using skip, added a test case showing the authentication failure for Ruby < 2.4.0, enforced logging and also changed the method suggested by @ekohl.

Let me know your thoughts on this.

rabajaj0509 · 2019-10-04T20:14:42Z

+    # OpenSSL#set_key method for all ruby version. We must remove this condition once new version
+    # of the JWT(2.2.2) is released.
+    unless OpenSSL::PKey::RSA.new.respond_to?(:set_key)
+      Foreman::Logging.logger('notifications').error "SSO feature is not available for Ruby < 2.4.0"


Added error logging in case of Ruby < 2.4.0. Here is an example log:

2019-10-04T15:41:12 [E|not|267ad15b] SSO feature is not available for Ruby < 2.4.0 2019-10-04T15:41:12 [E|app|267ad15b] JWT SSO: Failed to decode JWT. 2019-10-04T15:41:12 [W|app|267ad15b] SSO failed

rabajaj0509 · 2019-10-04T20:18:37Z

+      SSO::OpenidConnect.new api_controller({:authorization => "Bearer #{token}"})
+    end
+
+    test "It returns nil for Ruby < 2.4.0" do


Added a test for checking failure of authentication in case of Ruby < 2.4.0

This should test that the authentication fails and logs the correct message but only run on 2.3 (i.e. skip if RUBY_VERSION >= '2.4') instead of stubbing the method

ekohl

The use of jwt_token is redundant, right? JSON Web Token Token.

ekohl · 2019-10-04T22:13:08Z

+      :method => :get,
+      :verify_ssl => true
+    )
+    jwks_keys = JSON.parse(response)['keys']


JSON.parse(response) may not be a hash in which case it can fail. I don't think you're catching that exception.

Since you asked the question on IRC:

For this comment, when can a JSON not be a key-value pair?

Never assume content that comes from the network is in the shape you want. It's always good to think about failure cases. The user might have configured the URL incorrect and it's actually pointing to a different service that does return JSON for example.

ekohl · 2019-10-04T22:17:29Z

+class OidcJwtToken < JwtToken
+  def decode
+    return if token.blank?
+    raise JWT::DecodeError unless OidcJwtTokenValidate.new(token).valid_jwt?


In valid_jwt? you catch the JWT::DecodeError and return false. Here you raise another. That feels a bit odd to me. You're also decoding twice: once in the validate and if it's present. Then you discard that. Am I missing something or should these be combined?

ekohl · 2019-10-04T22:19:40Z

+    # OpenSSL#set_key method does not support ruby version < 2.4.0, apparently the JWT gem uses
+    # OpenSSL#set_key method for all ruby version. We must remove this condition once new version
+    # of the JWT(2.2.2) is released.
+    unless OpenSSL::PKey::RSA.new.respond_to?(:set_key)


Perhaps this should be in a supported? helper. I'd even consider raising a NotImplementedError

ekohl · 2019-10-04T22:23:46Z

+class OidcJwtTokenValidateTest < ActiveSupport::TestCase
+  context '#valid_jwt?' do
+    def setup
+      skip "SSO feature is not available for Ruby < 2.4.0" unless


This is the same code but it can easily hide problems. I'd actually use RUBY_VERSION here so you know it's tested on newer rubies.

ekohl · 2019-10-04T22:24:55Z

+    def setup
+      skip "SSO feature is not available for Ruby < 2.4.0" unless
+        OpenSSL::PKey::RSA.new.respond_to?(:set_key)
+      @jwk = JWT::JWK.new(OpenSSL::PKey::RSA.new(2048))


Generating private keys is slow, especially when entropy is low (common on VMs). This can easily blow up the test runtime. I'd consider a fixture.

rabajaj0509 · 2019-10-05T00:19:45Z

@ekohl i have worked on some of your comments(naming and #6549 (comment)) and will work on the others shortly.

tbrisker

see comments inline

tbrisker · 2019-10-06T11:21:32Z

+    # OpenSSL#set_key method for all ruby version. We must remove this condition once new version
+    # of the JWT(2.2.2) is released.
+    unless OpenSSL::PKey::RSA.new.respond_to?(:set_key)
+      Foreman::Logging.logger('notifications').error "SSO feature is not available for Ruby < 2.4.0"


This shouldn't be in the notifications logger, all auth related messages are logged in the app logger.

tbrisker · 2019-10-06T11:31:37Z

+  def decode
+    return if token.blank?
+    raise JWT::DecodeError unless OidcJwtValidate.new(token).valid_jwt?
+    payload = JWT.decode(token, nil, false)


Suggested change

payload = JWT.decode(token, nil, false)

decoded_payload

tbrisker · 2019-10-06T11:35:19Z

+      Foreman::Logging.logger('notifications').error "SSO feature is not available for Ruby < 2.4.0"
+      return false
+    end
+    return false if Setting['oidc_algorithm'].nil?


Should we also check the audience, jwks and issuer settings are set? Also, would it make sense to log here that the authentication failed due to missing setting?

@tbrisker:
Thanks for bringing this to notice! I double checked and found that if audience, jwks, issuer or algorithm are not set, its already caught as a JWT::DecodeError when we run JWT.decode(). Here are some sample logs

When issuer is missing:

'Failed to decode JWT' error (JWT::InvalidIssuerError): Invalid issuer. Expected , received https://keycloak.journalctl.org/auth/realms/hammer-cli

When algorithm is missing:

'Failed to decode JWT' error (JWT::IncorrectAlgorithm): Expected a different algorithm

I am hence, also removing this redundant check for algorithm from here.

tbrisker · 2019-10-06T11:51:05Z

+      SSO::OpenidConnect.new api_controller({:authorization => "Bearer #{token}"})
+    end
+
+    test "It returns nil for Ruby < 2.4.0" do


This should test that the authentication fails and logs the correct message but only run on 2.3 (i.e. skip if RUBY_VERSION >= '2.4') instead of stubbing the method

tbrisker · 2019-10-06T11:52:05Z

+  context '#valid_jwt?' do
+    def setup
+      skip "SSO feature is not available for Ruby < 2.4.0" unless
+        OpenSSL::PKey::RSA.new.respond_to?(:set_key)


Suggested change

OpenSSL::PKey::RSA.new.respond_to?(:set_key)

RUBY_VERSION >= '2.4'

tbrisker · 2019-10-06T12:56:56Z

+
+  private
+
+  def jwks_loader


This method should accept an options parameter or an :invalidate keyword arg that is used to invalidate cache (and should cache the response otherwise to avoid repeated calls to the server) - see https://github.com/jwt/ruby-jwt#json-web-key-jwk and https://github.com/jwt/ruby-jwt/blob/master/lib/jwt/jwk/key_finder.rb#L30

Something like this:

def jwks_loader(options) @cached_keys = nil if options[:invalidate] return @cached_keys if @cached_keys.present? response = RestClient::Request.execute( :url => Setting['oidc_jwks_url'], :method => :get, :verify_ssl => true ) json_response = JSON.parse(response) if json_response.is_a?(Hash) jwks_keys = json_response['keys'] @cached_keys = { keys: jwks_keys.map(&:symbolize_keys) } else raise JSON::ParserError.new('Invalid JWKS response') end rescue RestClient::Exception, SocketError, JSON::ParserError => e Foreman::Logging.exception('Failed to load the JWKS', e) @cached_keys = {} end

houndci-bot · 2019-10-06T17:06:43Z

+    ).first
+  rescue JWT::DecodeError => e
+    Foreman::Logging.exception('Failed to decode JWT', e)
+    return nil


Style/RedundantReturn: Redundant return detected.

ekohl · 2019-10-07T13:35:01Z

      self.set('idle_timeout', N_("Log out idle users after a certain number of minutes"), 60, N_('Idle timeout')),
      self.set('bcrypt_cost', N_("Cost value of bcrypt password hash function for internal auth-sources (4-30). Higher value is safer but verification is slower particularly for stateless API calls and UI logins. Password change needed to take effect."), 4, N_('BCrypt password cost')),
      self.set('bmc_credentials_accessible', N_("Permits access to BMC interface passwords through ENC YAML output and in templates"), true, N_('BMC credentials access')),
+      self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. For example if you are using Keycloak this url(https://<your keycloak server>/auth/realms/<realm name>/protocol/openid-connect/certs) would be found as `jwk_uri` at https://<your keycloak server>/auth/realms/<realm name>/.well-known/openid-configuration."), nil, N_('OIDC JWKs URL')),


Isn't the whole idea behind .well-known that software can rely on it and humans never need to care? As a user I don't know which of the two I should enter. If only the well-known one should be specified, I'd write something like:

Suggested change

self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. For example if you are using Keycloak this url(https://<your keycloak server>/auth/realms/<realm name>/protocol/openid-connect/certs) would be found as `jwk_uri` at https://<your keycloak server>/auth/realms/<realm name>/.well-known/openid-configuration."), nil, N_('OIDC JWKs URL')),

self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. Typically https://keycloak.example.com/auth/realms/<realm name>/.well-known/openid-configuration."), nil, N_('OIDC JWKs URL')),

ekohl · 2019-10-07T13:35:46Z

      self.set('bmc_credentials_accessible', N_("Permits access to BMC interface passwords through ENC YAML output and in templates"), true, N_('BMC credentials access')),
+      self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. For example if you are using Keycloak this url(https://<your keycloak server>/auth/realms/<realm name>/protocol/openid-connect/certs) would be found as `jwk_uri` at https://<your keycloak server>/auth/realms/<realm name>/.well-known/openid-configuration."), nil, N_('OIDC JWKs URL')),
+      self.set('oidc_audience', N_("Name of the OpenID Connect Audience that is being used for Authentication. For example in case of Keycloak this is the Client ID."), nil, N_('OIDC Audience')),
+      self.set('oidc_issuer', N_("The iss(issuer) claim identifies the principal that issued the JWT, which exists at a `/.well-known/openid-configuration` in case of most of the IDP's."), nil, N_('OIDC Issuer')),


Is iss(issuer) a typo? Maybe IDP should also be written out since most users don't know what it stands for.

iss(issuer) is a very term in the JWT world. It is one of the most important claims and this line is directly taken from the spec(https://tools.ietf.org/html/rfc7519#section-4.1.1). I would like to stick to it, if you don't mind?

I would add a space in between like the RFC did.

ekohl · 2019-10-07T13:36:13Z

+      self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. For example if you are using Keycloak this url(https://<your keycloak server>/auth/realms/<realm name>/protocol/openid-connect/certs) would be found as `jwk_uri` at https://<your keycloak server>/auth/realms/<realm name>/.well-known/openid-configuration."), nil, N_('OIDC JWKs URL')),
+      self.set('oidc_audience', N_("Name of the OpenID Connect Audience that is being used for Authentication. For example in case of Keycloak this is the Client ID."), nil, N_('OIDC Audience')),
+      self.set('oidc_issuer', N_("The iss(issuer) claim identifies the principal that issued the JWT, which exists at a `/.well-known/openid-configuration` in case of most of the IDP's."), nil, N_('OIDC Issuer')),
+      self.set('oidc_algorithm', N_("The algorithm with which JWT was encoded in the IDP."), nil, N_('OIDC Algorithm')),


Suggested change

self.set('oidc_algorithm', N_("The algorithm with which JWT was encoded in the IDP."), nil, N_('OIDC Algorithm')),

self.set('oidc_algorithm', N_("The algorithm used to encode the JWT in the IDP."), nil, N_('OIDC Algorithm')),

ekohl · 2019-10-07T13:38:33Z

+    if json_response.is_a?(Hash)
+      jwks_keys = json_response['keys']
+      @cached_keys = nil if options[:invalidate] # need to reload the keys
+      @cached_keys ||= { keys: jwks_keys.map(&:symbolize_keys) }


If there are cached keys, does that mean you don't need to fetch a response in the first place and the method could return early?

As @tbrisker explained here: #6549 (comment).

ekohl · 2019-10-07T13:40:34Z

+  context '#decoded_payload?' do
+    def setup
+      skip "SSO feature is not available for Ruby < 2.4.0" unless RUBY_VERSION >= '2.4'
+      @jwk = JWT::JWK.new(OpenSSL::PKey::RSA.new(2048))


Is setup ran for every test or only for the class? The test would be a lot faster if you could reuse the key.

tbrisker · 2019-10-07T14:36:12Z

+      jwks_keys = json_response['keys']
+      { keys: jwks_keys.map(&:symbolize_keys) }
+    else
+      raise JSON::ParserError.new('Invalid JWKS response')


instead of raising here you can log and return an empty hash (but still keep the rescue below in case JSON.parse fails)

ekohl · 2019-10-07T15:31:01Z

+attribute88:
+  name: oidc_jwks_url
+  category: Setting::Auth
+  default: 127.0.0.1


This default is very different from the description since it's not a URL. If there is no sane default, should it be empty?

ekohl · 2019-10-07T15:31:08Z

+  name: oidc_audience
+  category: Setting::Auth
+  default: 'rest-client'
+  description: 'Name of the OpenID Connect Audience that is being used for Authentication. For exmaple in case of Keycloak this is the Client ID.'


Suggested change

description: 'Name of the OpenID Connect Audience that is being used for Authentication. For exmaple in case of Keycloak this is the Client ID.'

description: 'Name of the OpenID Connect Audience that is being used for Authentication. For example in case of Keycloak this is the Client ID.'

ekohl · 2019-10-07T15:33:22Z

+  name: oidc_jwks_url
+  category: Setting::Auth
+  default: 127.0.0.1
+  description: 'OpenID Connect JSON Web Key Set(JWKS) URL. For example if you are using Keycloak this url(https://<your keycloak server>/auth/realms/<realm name>/protocol/openid-connect/certs) would be found as `jwk_uri` at https://<your keycloak server>/auth/realms/<realm name>/.well-known/openid-configuration.'


Should this be synced to the Ruby code?

timogoebel

Code looks good to me. I'm good with merging this.

@tbrisker: Feel free to merge at your own discretion. Note, we still need the packaging to be done.

tbrisker

LGTM as well, pending packaging. Great job @rahulbajaj0509 on pushing this through the very long process!
@ekohl - unless you have any other comments feel free to merge once the packaging side is ready.

ekohl

Overall 👍 besides some small textual nits

ekohl · 2019-10-08T11:49:34Z

      self.set('idle_timeout', N_("Log out idle users after a certain number of minutes"), 60, N_('Idle timeout')),
      self.set('bcrypt_cost', N_("Cost value of bcrypt password hash function for internal auth-sources (4-30). Higher value is safer but verification is slower particularly for stateless API calls and UI logins. Password change needed to take effect."), 4, N_('BCrypt password cost')),
      self.set('bmc_credentials_accessible', N_("Permits access to BMC interface passwords through ENC YAML output and in templates"), true, N_('BMC credentials access')),
+      self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. Typically https://keycloak.example.com/auth/realms/<realm name>/protocol/openid-connect/certs if you are using Keycloak as an IDP"), nil, N_('OIDC JWKs URL')),


Nit: I think it's possible to avoid the personal pronoun which generally the preferred style. Maybe a native speaker has a better suggestion

Suggested change

self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. Typically https://keycloak.example.com/auth/realms/<realm name>/protocol/openid-connect/certs if you are using Keycloak as an IDP"), nil, N_('OIDC JWKs URL')),

self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. Typically https://keycloak.example.com/auth/realms/<realm name>/protocol/openid-connect/certs when using Keycloak as an IDP"), nil, N_('OIDC JWKs URL')),

ekohl · 2019-10-08T11:50:51Z

      self.set('bcrypt_cost', N_("Cost value of bcrypt password hash function for internal auth-sources (4-30). Higher value is safer but verification is slower particularly for stateless API calls and UI logins. Password change needed to take effect."), 4, N_('BCrypt password cost')),
      self.set('bmc_credentials_accessible', N_("Permits access to BMC interface passwords through ENC YAML output and in templates"), true, N_('BMC credentials access')),
+      self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. Typically https://keycloak.example.com/auth/realms/<realm name>/protocol/openid-connect/certs if you are using Keycloak as an IDP"), nil, N_('OIDC JWKs URL')),
+      self.set('oidc_audience', N_("Name of the OpenID Connect Audience that is being used for Authentication. For example in case of Keycloak this is the Client ID."), nil, N_('OIDC Audience')),


Nit: phrasing could be a bit more compact. For example and in case are redundant.

Suggested change

self.set('oidc_audience', N_("Name of the OpenID Connect Audience that is being used for Authentication. For example in case of Keycloak this is the Client ID."), nil, N_('OIDC Audience')),

self.set('oidc_audience', N_("Name of the OpenID Connect Audience used for Authentication. In case of Keycloak this is the Client ID."), nil, N_('OIDC Audience')),

ekohl · 2019-10-08T11:55:19Z

+      assert_nil expected, actual
+    end
+
+    test 'if audiance is not valid' do


Suggested change

test 'if audiance is not valid' do

test 'if audience is not valid' do

ekohl

👍 from a packaging perspective.

ekohl · 2019-10-10T12:03:10Z

+
+    private
+
+    def jwt_token


I'd still like to avoid this naming (https://en.wikipedia.org/wiki/RAS_syndrome) but I won't block on it.

I understand but we're already using that in multiple places and it seems pretty common in general (e.g. https://www.google.com/search?q=%22jwt+token%22).

tbrisker

Thanks @rahulbajaj0509 and @timogoebel, @ekohl and everyone else who took part in reviewing!

tbrisker · 2019-10-10T12:12:50Z

Please add this in the headline features for 1.24 and where it makes sense in the manual (e.g. after https://theforeman.org/manuals/nightly/index.html#5.1.9UsingOAuth or https://theforeman.org/manuals/nightly/index.html#5.7ExternalAuthentication)

rabajaj0509 · 2019-10-10T12:26:50Z

Thanks a lot everyone! I think I made many mistakes and without your help I would have never learnt so many things.

Few points I want to add:

I was really struggling with the session handling part, I had to read about how sessions actually worked and @timogoebel pointed me out to the code and how to handle that properly.
There were many scenarios for test cases which I didn't think about and was not sure how to go about handling the JWT gem and its corresponding version handling. @tbrisker pointed me out to various links which finally helped me understand.
I am always in two-minds while selecting names for a method, also while defining descriptions for settings and have never been involved in packaging, so thanks to @ekohl for helping me with that!
Thanks to @ntkathole for testing the PR again and again as there were many changes made from time to time.
Thanks @gnurag @ares, @kgaikwad, @ofedoren for reviewing as well :)

ekohl · 2019-10-10T12:30:39Z

Building a feature that touches the system at a deep level does expose you to a lot of details :)

houndci-bot reviewed Mar 7, 2019

View reviewed changes

Comment thread app/services/jwt_token.rb Outdated

theforeman-bot added Needs testing Not yet reviewed labels Mar 7, 2019

This comment has been minimized.

Sign in to view

theforeman-bot added Waiting on contributor and removed Waiting on contributor labels Mar 10, 2019

This comment has been minimized.

Sign in to view

theforeman-bot added the Waiting on contributor label Mar 12, 2019

timogoebel added the WIP label Mar 12, 2019

timogoebel requested changes Mar 12, 2019

View reviewed changes

theforeman-bot removed the Not yet reviewed label Mar 12, 2019

theforeman-bot removed the Waiting on contributor label Mar 17, 2019

This comment has been minimized.

Sign in to view

theforeman-bot added Needs re-review Waiting on contributor labels Mar 17, 2019

houndci-bot reviewed Mar 17, 2019

View reviewed changes

Comment thread app/services/jwt_token_validate.rb Outdated

Comment thread app/services/jwt_token_validate.rb Outdated

Comment thread app/services/jwt_token_validate.rb Outdated

Comment thread app/services/jwt_token_validate.rb Outdated

Comment thread app/services/jwt_token_validate.rb Outdated

theforeman-bot removed the Waiting on contributor label Mar 17, 2019

This comment has been minimized.

Sign in to view

theforeman-bot added the Waiting on contributor label Mar 17, 2019

houndci-bot reviewed Mar 17, 2019

View reviewed changes

Comment thread app/services/jwt_token_validate.rb Outdated

ares previously requested changes Mar 18, 2019

View reviewed changes

theforeman-bot removed the Needs re-review label Mar 18, 2019

theforeman-bot added Needs re-review and removed Waiting on contributor labels Mar 20, 2019

This comment has been minimized.

Sign in to view

theforeman-bot added the Waiting on contributor label Mar 20, 2019

houndci-bot reviewed Mar 20, 2019

View reviewed changes

Comment thread app/services/jwt_token_validate.rb Outdated

tbrisker reviewed Oct 3, 2019

View reviewed changes

Comment thread app/services/sso/openid_connect.rb Outdated

ekohl reviewed Oct 3, 2019

View reviewed changes

Comment thread app/services/sso/jwt.rb Outdated

houndci-bot reviewed Oct 4, 2019

View reviewed changes

Comment thread test/unit/oidc_jwt_token_validate_test.rb Outdated

Comment thread test/unit/oidc_jwt_token_validate_test.rb Outdated

rabajaj0509 commented Oct 4, 2019

View reviewed changes

ekohl reviewed Oct 4, 2019

View reviewed changes

houndci-bot reviewed Oct 5, 2019

View reviewed changes

Comment thread app/services/oidc_jwt_validate.rb Outdated

tbrisker suggested changes Oct 6, 2019

View reviewed changes

houndci-bot reviewed Oct 6, 2019

View reviewed changes

tbrisker reviewed Oct 6, 2019

View reviewed changes

Comment thread app/services/oidc_jwt_validate.rb

tbrisker reviewed Oct 7, 2019

View reviewed changes

Comment thread app/services/sso/openid_connect.rb Outdated

houndci-bot reviewed Oct 7, 2019

View reviewed changes

Comment thread app/services/oidc_jwt_validate.rb Outdated

ekohl reviewed Oct 7, 2019

View reviewed changes

tbrisker reviewed Oct 7, 2019

View reviewed changes

Comment thread app/services/oidc_jwt_validate.rb Outdated

tbrisker reviewed Oct 7, 2019

View reviewed changes

ekohl reviewed Oct 7, 2019

View reviewed changes

tbrisker reviewed Oct 7, 2019

View reviewed changes

Comment thread test/unit/sso/openid_connect_test.rb

timogoebel previously approved these changes Oct 8, 2019

View reviewed changes

tbrisker previously approved these changes Oct 8, 2019

View reviewed changes

Comment thread app/services/sso/jwt.rb

ekohl previously approved these changes Oct 8, 2019

View reviewed changes

Fixes #25809 - JWT auth for external users

4cf928a

ekohl mentioned this pull request Oct 10, 2019

Update tfm-rubygem-jwt to 2.2.1 theforeman/foreman-packaging#4182

Merged

ekohl approved these changes Oct 10, 2019

View reviewed changes

tbrisker approved these changes Oct 10, 2019

View reviewed changes

	OpenSSL::PKey::RSA.new.respond_to?(:set_key)
	RUBY_VERSION >= '2.4'

	self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. For example if you are using Keycloak this url(https://<your keycloak server>/auth/realms/<realm name>/protocol/openid-connect/certs) would be found as `jwk_uri` at https://<your keycloak server>/auth/realms/<realm name>/.well-known/openid-configuration."), nil, N_('OIDC JWKs URL')),
	self.set('oidc_jwks_url', N_("OpenID Connect JSON Web Key Set(JWKS) URL. Typically https://keycloak.example.com/auth/realms/<realm name>/.well-known/openid-configuration."), nil, N_('OIDC JWKs URL')),

	self.set('oidc_algorithm', N_("The algorithm with which JWT was encoded in the IDP."), nil, N_('OIDC Algorithm')),
	self.set('oidc_algorithm', N_("The algorithm used to encode the JWT in the IDP."), nil, N_('OIDC Algorithm')),

	description: 'Name of the OpenID Connect Audience that is being used for Authentication. For exmaple in case of Keycloak this is the Client ID.'
	description: 'Name of the OpenID Connect Audience that is being used for Authentication. For example in case of Keycloak this is the Client ID.'

	self.set('oidc_audience', N_("Name of the OpenID Connect Audience that is being used for Authentication. For example in case of Keycloak this is the Client ID."), nil, N_('OIDC Audience')),
	self.set('oidc_audience', N_("Name of the OpenID Connect Audience used for Authentication. In case of Keycloak this is the Client ID."), nil, N_('OIDC Audience')),

	test 'if audiance is not valid' do
	test 'if audience is not valid' do

Conversation

rabajaj0509 commented Mar 7, 2019

Uh oh!

Uh oh!

theforeman-bot commented Mar 7, 2019

Uh oh!

This comment has been minimized.

This comment has been minimized.

timogoebel left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

rabajaj0509 commented Mar 13, 2019

Uh oh!

This comment has been minimized.

Uh oh!

Uh oh!

Uh oh!

Uh oh!

Uh oh!

This comment has been minimized.

Uh oh!

ares left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rabajaj0509 commented Mar 18, 2019

Uh oh!

This comment has been minimized.

Uh oh!

rabajaj0509 commented Oct 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

tbrisker left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

rabajaj0509 Oct 3, 2019 • edited Loading Uh oh! There was an error while loading. Please reload this page.

rabajaj0509 commented Oct 3, 2019 •

edited

Loading

rabajaj0509 Oct 3, 2019 •

edited

Loading

ekohl Oct 5, 2019 •

edited

Loading