Hi Indunil, A few more details.
On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[email protected]> wrote: > Hi Indunil, > > Please see my comments inline. > > On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake < > [email protected]> wrote: > >> Hi, >> >> Thanks all of your valuable feedbacks. Currently we are implementing >> following REST endpoints. We have modeled the the rest API using swagger >> and you can find the attached swagger definition as well. Really appreciate >> your comments and suggestions on the specified endpoints, please mention if >> there are other required endpoints. >> >> >> Endpoint Method Usage Request Body Response >> /scopes POST Create Scopes [{"key": "openid", "name": "openid", >> "description": "openid scope", "bindings": ["role1", "role2"]}] "HTTP/1.1 >> 201 Created" >> > > Here the request body is a json array. Does that mean we can create > multiple scopes at once? If not, let's get rid of wrappering squire > brackets. > My +1 is to have multiple scopes in the request. > > >> >> DELETE Delete Scopes ["key1", "key2"] "HTTP/1.1 201 Deleted" >> >> PUT Update Scopes [{"key": "openid", "name": "openid", "description": >> "openid scope", "bindings": ["role3"]}] "HTTP/1.1 201 Updated" >> > > In these 2 cases the status code should be 200. (We may also use 204 for > delete like DCRM spec does.) > >From the http spec https://tools.ietf.org/html/rfc2616#section-9.7 : A successful response SHOULD be 200 (OK) if the response includes an entity describing the status, 202 (Accepted) if the action has not yet been enacted, or 204 (No Content) if the action has been enacted but the response does not include an entity. So you can choose between 200 or 204 depending on the response body you send back. Further, instead of sending a request body in the DELETE request (which is not restricted by the spec though), we can send it like this. DELETE /scopes?keys=key1,key2 WDYT? Thanks, Bhathiya > > >> /scopes?filter=maxResults+Eq+100 GET Get all available Scopes >> [{"key": "openid", "name": "openid", "description": "openid scope", >> "bindings": []}] >> >> /scopes/by-bindings GET Get Scopes by Binding/s {"bindings": ["role1", >> "role2"]} [{"key": "openid", "name": "openid", "description": "openid >> scope", "bindings": ["role1", "role2"]}] >> > > This should be a POST if you have a request body. Instead of that, how > about something like this? > > /scopes?bindings=role1,role2 > > >> >> /scopes/keys GET Get all the available >> Scope Keys >> ["key1", "key2"] >> >> /scopes/keys/by-bindings GET Get Scope keys >> by Binding/s {"bindings": ["role1", "role2"]} ["key1", "key2"] >> > > We can do the same here. > > /scopes/keys?bindings=role1,role2 > > >> >> /scopes/{scope_key} GET Get a Scope by Scope Key >> {"key": "openid", "name": "openid", "description": "openid scope", >> "bindings": []} >> >> DELETE Delete a Scope by >> Scope Key >> "HTTP/1.1 201 Deleted" >> >> PUT Update a Scope by >> Scope Key {"key": "openid", "name": "openid", "description": "openid >> scope", "bindings": ["role3", "role4"]} "HTTP/1.1 201 Updated" >> > > Need to change the status codes as suggested above. > > Thanks, > Bhathiya > > >> >> >> @Nuwan: We have a suggestion to modified the database schema as follows >> to properly store bindings (considering the performance issues in using >> comma separated values and renaming the "ROLES" field to a generic name), >> but need to discuss about this and finalize. >> >> >> >> Appreciate your comments and suggestions and I will arrange a meeting >> tomorrow to have a further discussion on this. >> >> Thanks and Regards >> >> >> On Mon, Jun 12, 2017 at 2:53 AM, Nuwan Dias <[email protected]> wrote: >> >>> >>> On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake < >>> [email protected]> wrote: >>> >>>> Hi, >>>> >>>> We are currently working on implementing following features which are >>>> needed for APIM 3.0. You can find the initial discussion details in [1]. >>>> >>>> 1. Sign UserInfo JWT response >>>> 2. Scope registration and Scope binding >>>> 3. DCRM >>>> >>>> >>>> *Sign UserInfo JWT response:* >>>> JWT user info response signing implementation is in [1]. >>>> >>>> Currently in APIM, there is a key manager global wise configuration to >>>> configure needed claims which needed to be send in user info response. We >>>> need to consider, when no SP wise requested claims are configured as in >>>> APIM, whether we need to send all the claims bound for a specific scope in >>>> oidc-scope-config.xml. >>>> Currently in IS, we are sending only those claims which are common in >>>> both OIDC scope config and SP claim configuration (ie. intersection of >>>> claim in both these configs). >>>> >>>> *Shall we send all the bounded claims if requested claims are not >>>> defined?* >>>> >>>> *Scope registration and Scope binding:* >>>> New endpoints will be exposed in IS 5.4.0 to handle Scope register, >>>> bind, update, delete, list etc. >>>> >>>> As per the current implementation of APIM and IoT, following things can >>>> be noticed and have following concerns. >>>> >>>> - Scope can be bound with roles or permissions - Uses scope to role >>>> binding in APIM and uses scope to permission binding in IoT. >>>> >>>> >>>> - Both of the above bindings are stored in "IDN_OAUTH2_SCOPE" table >>>> where roles and permissions both are stored as a comma separated string >>>> in >>>> same column named "ROLES". AFAIU, there is no indication with a prefix >>>> in >>>> scope registration, where to separate the two bindings. *There can >>>> be other bindings which will be added in future, isn't it better to >>>> renamed >>>> the field as "BINDINGS"? There can be a situation where both set of >>>> roles >>>> and permissions are bound to a scope?* >>>> >>>> Its better to rename but please note that this is a minor version >>> upgrade and hence it's better to avoid schema changes. >>> >>>> >>>> - >>>> >>>> >>>> - In scope validation, currently there are validators for role >>>> based and permission based. The corresponding validator will be selected >>>> based on the prefix (ex: Permission based scope validator only validates >>>> the scope which are having "perm" as the prefix of the scopes) and if >>>> scope >>>> prefix is not defined, those will directly go to the default role based >>>> scope validator. *How this prefix has to be considered and >>>> validated in scope registration with the bindings?* >>>> >>>> >>>> - In scope registration, AFAIU, scope key and name are the >>>> essential details to be included. *What is the difference of theses >>>> and where these values will be used? scope key is the unique value which >>>> need to be considered in scope binding?* >>>> >>>> >>>> 1. Scope Register and Bind >>>> There can be following scenarios a scope can be registered and bound. >>>> CreateScope - scope key, scope name, roles >>>> CreateScope - scope key, scope name, permissions >>>> CreateScope - scope key, scope name >>>> >>>> So that we have implemented "/api/identity/oauth2/scope/v0.9/registerScope" >>>> endpoint to register set of scopes with the bindings. "key" and "name" >>>> cannot be null and bindings(added a generic property rather adding two >>>> properties for roles and permissions) will be stored as comma separated >>>> values in IDN_OAUTH2_SCOPE table. >>>> >>>>> {"scope": [{"key": "openid", "name": "openid", "description": "openid >>>>> scope", "bindings": ["role1", "role2"]}]} >>>>> >>>> >>>> 2. Scope Update >>>> "/updateScope" endpoint to update a set of scopes with the bindings >>>> which need to be added and deleted. >>>> >>>>> {"scope": [{"key": "openid", "addedBindings": ["role3"], >>>>> "deletedBindings": ["role2"]}]} >>>>> >>>> >>>> 3. Scope Delete >>>> "/deleteScope" endpoint to delete a set of scopes. >>>> >>>>> {"scope": ["scope_key_1", "scope_key_2"]} >>>>> >>>> >>>> 4. Scope List >>>> Endpoints for following scenarios. >>>> 1. Get scope by key >>>> 2. Get scope key list by role/s - given a role or role list, return the >>>> list of scope keys that includes all of those roles >>>> 3. Get scope key list by permission/s - given a permission or >>>> permission list, return the list of scope keys that includes all of those >>>> permissions >>>> 4. Get scopes by role/s - for a given role or role list, return the >>>> list of scopes that includes all of those roles with all the details >>>> 5. Get scopes by permission/s - for a given permission or permission >>>> list, return the list of scopes that includes all of those permissions with >>>> all the details >>>> 6. Get all the available scope keys >>>> 7. Get all the available scopes with their description and allocated >>>> roles/permissions >>>> >>>> Appreciate your comments and suggestions on this. >>>> >>>> >>>> *DCRM:* >>>> Abilashini is working on this as a GSoC project and discussion is in >>>> [3]. >>>> >>>> >>>> [1] Discussion on features which required for APIM to be incl... @ Tue >>>> May 30, 2017 10:30am - 12pm (IST) (WSO2 Engineering Group) >>>> [2] https://github.com/wso2-extensions/identity-inbound-auth-oau >>>> th/pull/385 >>>> [3] [Dev] GSOC : OAuth 2.0 Dynamic Client Registration Management >>>> Protocol Support >>>> >>>> Thanks and Regards >>>> >>>> >>>> -- >>>> Indunil Upeksha Rathnayake >>>> Software Engineer | WSO2 Inc >>>> Email [email protected] >>>> Mobile 0772182255 <077%20218%202255> >>>> >>> -- >>> Nuwan Dias >>> >>> Software Architect - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 <+94%2077%20777%205729> >>> >> >> >> >> -- >> Indunil Upeksha Rathnayake >> Software Engineer | WSO2 Inc >> Email [email protected] >> Mobile 0772182255 <077%20218%202255> >> > > > > -- > *Bhathiya Jayasekara* > *Associate Technical Lead,* > *WSO2 inc., http://wso2.com <http://wso2.com>* > > *Phone: +94715478185 <071%20547%208185>* > *LinkedIn: http://www.linkedin.com/in/bhathiyaj > <http://www.linkedin.com/in/bhathiyaj>* > *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* > *Blog: http://movingaheadblog.blogspot.com > <http://movingaheadblog.blogspot.com/>* > -- *Bhathiya Jayasekara* *Associate Technical Lead,* *WSO2 inc., http://wso2.com <http://wso2.com>* *Phone: +94715478185* *LinkedIn: http://www.linkedin.com/in/bhathiyaj <http://www.linkedin.com/in/bhathiyaj>* *Twitter: https://twitter.com/bhathiyax <https://twitter.com/bhathiyax>* *Blog: http://movingaheadblog.blogspot.com <http://movingaheadblog.blogspot.com/>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
