Project

General

Profile

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. 

Back