- Nov 19, 2020
-
-
Álvaro López García authored
The redirection URL should not be configured by the user, but rather be generated by us. We need to check if the request is from the CLI (passing localhost as the redirection URL) or from Keystone itself.
-
-
Álvaro López García authored
-
Álvaro López García authored
-
Álvaro López García authored
-
Álvaro López García authored
-
Álvaro López García authored
-
Álvaro López García authored
-
Álvaro López García authored
-
Álvaro López García authored
In order to better adhere to the OpenID Connect specs, the Keystone server must be the OpenID Connect client (Relying Party). This means that the auth flow should be handled by the Keystone app (the RP), and not the OpenStack clients. The OpenID Connect requires that the user authorizes the request in the OpenID Connect Provider (OP), meaning that the RP must interact with the user-agent (the browser in this case) for authentication. However, in the case of CLI applications, it is not easy to perform this authorization request. We implement out-of-bound authorization as follows: - The OpenStack CLI makes a post request to the Keystone Federation endpoint (RP), configured to use OpenID Connect, specifying a special parameter (oscli=1) in the query string. This indicates out-of-bound execution. - The Keystone Federation endpoint redirects the user to the OP in order to authorize the request. The redirect_uri that is passed to the OP so that the auth request callback is performed is not a URL from the RP, but http://localhost:8080 - The OpenStack CLI spawns a http server in localhost:8080 and it waits for the authorization code. - The user authorizes the request in the OP, then it is redirected to http://localhost:8080 - The OpenStack CLI gets the code, and completes the auth request, by contacting again the Keystone Federation endpoint with the auth code.
-
Álvaro López García authored
-
-
-
-
- Nov 26, 2019
-
-
Álvaro López García authored
-
Álvaro López García authored
-
-
-
-
- Jul 23, 2019
-
-
Álvaro López García authored
-
Álvaro López García authored
Since the access token is a JWT we can rely on pyoidc to verify it using the keyjar that has been retrieved from the server.
-
Álvaro López García authored
Rather than parsing the headers we can rely on pyoidc to verify that the header is correctly set.
-
- Jul 05, 2019
-
-
Álvaro López García authored
-
Álvaro López García authored
Keystone federation registers the "remote_id_attribute" option for each of the protocols. We can register it ourselves, so that it gets documented in the generated configuration file.
-
Álvaro López García authored
Add a sample configuration file
-
Álvaro López García authored
-
Álvaro López García authored
Rather than relying on dictionaries we can rely on different sections, prefixed by openid, like: [openid_foo] issuer = foo client_id = foobar [openid_bar] issuer = bar client_id = foobarbaz
-
Álvaro López García authored
We should not mimic downstream code, but rather set up the required ENV vars to ensure that the assertions can be consumed downstream by all the federation plumbing.
-
Álvaro López García authored
-
Álvaro López García authored
-
-
Solved style issues and fixed unit testing
-
-
-
- Apr 25, 2019
-
-
Álvaro López García authored
-
Álvaro López García authored
Fix #1
-
- Aug 01, 2018
-
-
Álvaro López García authored
-
Álvaro López García authored
-
Álvaro López García authored
-
Álvaro López García authored
-