Handle incoming OpenID RISC Events (LG-3119)#3967
Conversation
zachmargolis
requested review from
achapm,
adunkman,
aduth,
jmhooper,
mitchellhenke and
stevegsa
and removed request for
adunkman
| delivery: [ | ||
| { | ||
| delivery_method: DELIVERY_METHOD_PUSH, | ||
| url: api_security_events_url, | ||
| }, | ||
| ] |
There was a problem hiding this comment.
Adding a delivery clause here was something I kind of made up...
The spec allows for dynamic registration of various endpoints, and the responses there contain sections like this: https://openid.net/specs/openid-risc-profile-1_0-ID1.html#rfc.section.4.1.2.1
The section on HTTP Push (which we support) describes these parts, so I just figured they seemed like a good thing to add because the HTTP Push Doc doesn't seem to include anything about discovery, just how the endpoint should act
| t.string :issuer | ||
| t.timestamps | ||
| end | ||
| add_index :security_events, ["jti"], name: "index_security_events_on_jti" |
There was a problem hiding this comment.
this was a guess that we might want it in the future, in case we ever want to find an event that somebody gave us?
Using t.references gives us an index on user_id so that access pattern is already taken care of
| module Risc | ||
| class ConfigurationController < ApplicationController | ||
| def index | ||
| render json: RiscConfigurationPresenter.new.configuration |
There was a problem hiding this comment.
When I added the OpenID discovery endpoint, I added caching headers because I'm pretty sure some specification required it....but I can't find it and didn't see any caching direction on the specs for this. I left out caching, but it's a one-liner so happy to add it if anybody feels strongly
mitchellhenke
left a comment
mitchellhenke
left a comment
There was a problem hiding this comment.
Only one question from me, looks good 🙂
4 participants
This is a first PR to support the new RISC (Risk and Incident Sharing and Coordination) framework outlined by the OpenID folks: https://openid.net/specs/openid-risc-profile-1_0-ID1.html
There were a bunch of docs I jumped between to pull this together, I tried to link out to docs where I figured things might be unclear
This first stab creates an endpoint where issuers can submit events to us, and events that are validated get written to our DB
Open future questions:
There are a few places the specs were "TODO" or unclear, so I'll drop comments where I took some guesses