Feature #17038
Updated by Peter Amstutz over 3 years ago
Something like this: <pre><code class="yaml"> OpenIDConnect: # ... # Send additional scope values (along with "openid") in order to request additional claims. Space-separated, case sensitive. RequestScopes: "profile email" # Verify that the following claims are returned by the provider (and not empty); otherwise, refuse login. Space-separated, case sensitive. RequireClaims: "" </code></pre> h2. PA comments my understanding was that the flow was something like this: # client sends user to login, and asks for a list of scopes. We could define scopes associated with arvados clusters as "arvados:clusterid" eg arvados:su92l" # User agrees to the scopes (or not) # List of scopes are stored as part of the token # The consumer of the token can check for a specific scope to see if the user authorized a given action * some scopes are special and defined in the spec because they affect the behavior of the OIDC APIs * token issuers can restrict the ability to request scopes by client id, so that e.g. mycoolwebsite.com wouldn't be able to get a token that has the "arvados:su92l" arvados-su92l scope unless the provider granted permission to do so to mycoolwebsite.com's client id. We need a new config knob for which scope(s) we require when accepting tokens that were issued for other clients.