-
Notifications
You must be signed in to change notification settings - Fork 5
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
OIDC post endpoint #214
OIDC post endpoint #214
Conversation
7a8e91c
to
c6a0292
Compare
@@ -63,10 +63,38 @@ def login username, password, account: Conjur.configuration.account | |||
# @param [Hash] params Additional params to send to authenticator | |||
# @return [String] A JSON formatted authentication token. | |||
def authenticator_authenticate authenticator, service_id, account: Conjur.configuration.account, options: {} | |||
JSON.parse authenticator_authenticate_post authenticator, service_id, account: account, options: options |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Should the default behavior of authenticator_authenticate
be to use the POST method?
If yes - should the GET routing be removed entirely?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, probably. Optimally, we would use the endpoint that is credential-agnostic for code and refresh token exchanges.
Through our progress so far on the refresh token feature branch, we've maintained the GET behavior for backwards-compatibility. Maybe we should consider maintaining it here, too, until we officially remove it.
Then the response body contains: "payload" | ||
And the response includes headers | ||
|
||
Scenario: Authenticate with OIDC code requesting unparsed result via POST method |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Two scenarios relying on the updated Conjur OIDC API currently fail in CI since the functionality has yet to be merged. The tests pass when run locally against a Conjur build containing those updates.
c6a0292
to
389b9a2
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM, but blocked by the status of the refresh token feature branch.
Closing. OIDC refresh token support was dropped in favor of a configurable Conjur token TTL implemented in cyberark/conjur#2683. |
Desired Outcome
Extend the Conjur Ruby API to submit POST requests to the OIDC authentication endpoint.
This new function needs to be able to return a raw RestClient::Response object as it will be used for OIDC refresh token exchanged by Conjur UI.
Implemented Changes
Definition of Done
At least 1 todo must be completed in the sections below for the PR to be
merged.
Changelog
CHANGELOG update
Test coverage
changes, or
Documentation
README
s) were updated in this PRBehavior
Security