Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

classic Classic list List threaded Threaded
11 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Indunil Upeksha Rathnayake
Adding lakmal and sanjeewa

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate Scopes[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}]"HTTP/1.1 201 Created"

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate Scopes[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": ["role3"]}]"HTTP/1.1 201 Updated"
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet Scopes by Binding/s{"bindings": ["role1", "role2"]}[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}]

/scopes/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate a Scope by
Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 201 Updated"


@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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Bhathiya Jayasekara
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)


 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+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Isura Karunaratne
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810




_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Indunil Upeksha Rathnayake


On Fri, Jun 23, 2017 at 12:48 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

In error cases shall we send a response like this?

     {
      "error": "invalid_scope_name",
      "error_description": "Scope name cannot contain white spaces"
     }

Currently the error response body is like this. Is it fine to remain as it is or change as you have suggested?
{
    "code": "18005",
    "message": "Conflict",
    "description": "Scope with the name openid already exists in the system. Please use a different scope name."
}
 
And I think /scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586 is the same as /scopes/{scope_id}.
So we can remove the former.
Yeah. I'll remove that, and if so filtering would be only based on scope name.
 

Thanks,
Bhathiya

On Fri, Jun 23, 2017 at 12:33 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had in [1], there were some database schema changes and endpoint changes were suggested(You can find more details in [1]). Please find the following details on the current database schema changes and endpoints.

Database Schema Change:





Endpoints:

EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate a Scope{"name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}
"HTTP/1.1 201 Created"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}


If name/description is not defined or empty - "HTTP/1.1 400 Bad Request"

If already available scope name - "HTTP/1.1 409 Conflict"
/scopes
GETList Scopes
"HTTP/1.1 200 OK"
[{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}]

"HTTP/1.1 404 Not Found"
An empty array if no scopes exist
/scopes?startIndex=1&count=2GETList Scopes With Pagination
/scopes?filter=name Eq openid
/scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586
GET
List Scopes with Filter





/scopes/names/{scope_name}HEADCheck whether a scope name
exists

"HTTP/1.1 200 OK"

"HTTP/1.1 404 Not Found"

/scopes/{scope_id}GETGet a Scope by Scope ID
"HTTP/1.1 200 OK"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}

"HTTP/1.1 404 Not Found"

DELETEDelete a Scope by
Scope ID

"HTTP/1.1 204 No Content"

PUTUpdate a Scope by
Scope ID
{"name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 200 OK"

If already available scope name -
"HTTP/1.1 409 Conflict"



[1] [IS] [Architecture] Discussion on the REST endpoints and database schema changes for scope bindings which to be included in IS 5.4.0

Thanks and Regards

On Thu, Jun 22, 2017 at 2:56 PM, Isura Karunaratne <[hidden email]> wrote:
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Bhathiya Jayasekara

On Fri, Jun 23, 2017 at 1:10 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:


On Fri, Jun 23, 2017 at 12:48 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

In error cases shall we send a response like this?

     {
      "error": "invalid_scope_name",
      "error_description": "Scope name cannot contain white spaces"
     }

Currently the error response body is like this. Is it fine to remain as it is or change as you have suggested?
{
    "code": "18005",
    "message": "Conflict",
    "description": "Scope with the name openid already exists in the system. Please use a different scope name."
}

This is fine. 

Thanks,
Bhathiya
 
 
And I think /scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586 is the same as /scopes/{scope_id}.
So we can remove the former.
Yeah. I'll remove that, and if so filtering would be only based on scope name.
 

Thanks,
Bhathiya

On Fri, Jun 23, 2017 at 12:33 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had in [1], there were some database schema changes and endpoint changes were suggested(You can find more details in [1]). Please find the following details on the current database schema changes and endpoints.

Database Schema Change:





Endpoints:

EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate a Scope{"name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}
"HTTP/1.1 201 Created"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}


If name/description is not defined or empty - "HTTP/1.1 400 Bad Request"

If already available scope name - "HTTP/1.1 409 Conflict"
/scopes
GETList Scopes
"HTTP/1.1 200 OK"
[{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}]

"HTTP/1.1 404 Not Found"
An empty array if no scopes exist
/scopes?startIndex=1&count=2GETList Scopes With Pagination
/scopes?filter=name Eq openid
/scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586
GET
List Scopes with Filter





/scopes/names/{scope_name}HEADCheck whether a scope name
exists

"HTTP/1.1 200 OK"

"HTTP/1.1 404 Not Found"

/scopes/{scope_id}GETGet a Scope by Scope ID
"HTTP/1.1 200 OK"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}

"HTTP/1.1 404 Not Found"

DELETEDelete a Scope by
Scope ID

"HTTP/1.1 204 No Content"

PUTUpdate a Scope by
Scope ID
{"name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 200 OK"

If already available scope name -
"HTTP/1.1 409 Conflict"



[1] [IS] [Architecture] Discussion on the REST endpoints and database schema changes for scope bindings which to be included in IS 5.4.0

Thanks and Regards

On Thu, Jun 22, 2017 at 2:56 PM, Isura Karunaratne <[hidden email]> wrote:
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Chathura Ekanayake
Do we store resource -> scope mappings in IS? If so, I think IS has to expose an API to add those. If not, how does IS access those mappings for token validation?

Regards,
Chathura

On Fri, Jun 23, 2017 at 1:23 PM, Bhathiya Jayasekara <[hidden email]> wrote:

On Fri, Jun 23, 2017 at 1:10 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:


On Fri, Jun 23, 2017 at 12:48 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

In error cases shall we send a response like this?

     {
      "error": "invalid_scope_name",
      "error_description": "Scope name cannot contain white spaces"
     }

Currently the error response body is like this. Is it fine to remain as it is or change as you have suggested?
{
    "code": "18005",
    "message": "Conflict",
    "description": "Scope with the name openid already exists in the system. Please use a different scope name."
}

This is fine. 

Thanks,
Bhathiya
 
 
And I think /scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586 is the same as /scopes/{scope_id}.
So we can remove the former.
Yeah. I'll remove that, and if so filtering would be only based on scope name.
 

Thanks,
Bhathiya

On Fri, Jun 23, 2017 at 12:33 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had in [1], there were some database schema changes and endpoint changes were suggested(You can find more details in [1]). Please find the following details on the current database schema changes and endpoints.

Database Schema Change:





Endpoints:

EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate a Scope{"name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}
"HTTP/1.1 201 Created"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}


If name/description is not defined or empty - "HTTP/1.1 400 Bad Request"

If already available scope name - "HTTP/1.1 409 Conflict"
/scopes
GETList Scopes
"HTTP/1.1 200 OK"
[{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}]

"HTTP/1.1 404 Not Found"
An empty array if no scopes exist
/scopes?startIndex=1&count=2GETList Scopes With Pagination
/scopes?filter=name Eq openid
/scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586
GET
List Scopes with Filter





/scopes/names/{scope_name}HEADCheck whether a scope name
exists

"HTTP/1.1 200 OK"

"HTTP/1.1 404 Not Found"

/scopes/{scope_id}GETGet a Scope by Scope ID
"HTTP/1.1 200 OK"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}

"HTTP/1.1 404 Not Found"

DELETEDelete a Scope by
Scope ID

"HTTP/1.1 204 No Content"

PUTUpdate a Scope by
Scope ID
{"name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 200 OK"

If already available scope name -
"HTTP/1.1 409 Conflict"



[1] [IS] [Architecture] Discussion on the REST endpoints and database schema changes for scope bindings which to be included in IS 5.4.0

Thanks and Regards

On Thu, Jun 22, 2017 at 2:56 PM, Isura Karunaratne <[hidden email]> wrote:
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185


_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Indunil Upeksha Rathnayake
Hi,

As per the discussion we had before with APIM team, resource -> scope mappings will be handled in APIM side and not needed to expose an API for that.

Thanks and Regards

On Wed, Jun 28, 2017 at 11:39 AM, Chathura Ekanayake <[hidden email]> wrote:
Do we store resource -> scope mappings in IS? If so, I think IS has to expose an API to add those. If not, how does IS access those mappings for token validation?

Regards,
Chathura

On Fri, Jun 23, 2017 at 1:23 PM, Bhathiya Jayasekara <[hidden email]> wrote:

On Fri, Jun 23, 2017 at 1:10 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:


On Fri, Jun 23, 2017 at 12:48 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

In error cases shall we send a response like this?

     {
      "error": "invalid_scope_name",
      "error_description": "Scope name cannot contain white spaces"
     }

Currently the error response body is like this. Is it fine to remain as it is or change as you have suggested?
{
    "code": "18005",
    "message": "Conflict",
    "description": "Scope with the name openid already exists in the system. Please use a different scope name."
}

This is fine. 

Thanks,
Bhathiya
 
 
And I think /scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586 is the same as /scopes/{scope_id}.
So we can remove the former.
Yeah. I'll remove that, and if so filtering would be only based on scope name.
 

Thanks,
Bhathiya

On Fri, Jun 23, 2017 at 12:33 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had in [1], there were some database schema changes and endpoint changes were suggested(You can find more details in [1]). Please find the following details on the current database schema changes and endpoints.

Database Schema Change:





Endpoints:

EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate a Scope{"name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}
"HTTP/1.1 201 Created"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}


If name/description is not defined or empty - "HTTP/1.1 400 Bad Request"

If already available scope name - "HTTP/1.1 409 Conflict"
/scopes
GETList Scopes
"HTTP/1.1 200 OK"
[{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}]

"HTTP/1.1 404 Not Found"
An empty array if no scopes exist
/scopes?startIndex=1&count=2GETList Scopes With Pagination
/scopes?filter=name Eq openid
/scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586
GET
List Scopes with Filter





/scopes/names/{scope_name}HEADCheck whether a scope name
exists

"HTTP/1.1 200 OK"

"HTTP/1.1 404 Not Found"

/scopes/{scope_id}GETGet a Scope by Scope ID
"HTTP/1.1 200 OK"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}

"HTTP/1.1 404 Not Found"

DELETEDelete a Scope by
Scope ID

"HTTP/1.1 204 No Content"

PUTUpdate a Scope by
Scope ID
{"name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 200 OK"

If already available scope name -
"HTTP/1.1 409 Conflict"



[1] [IS] [Architecture] Discussion on the REST endpoints and database schema changes for scope bindings which to be included in IS 5.4.0

Thanks and Regards

On Thu, Jun 22, 2017 at 2:56 PM, Isura Karunaratne <[hidden email]> wrote:
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185




--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Chathura Ekanayake
Hi Indunil,

I guess IS needs to access resource -> scope mappings for token validation when acting as a key manager. If those mappings are maintained in APIM, IS has to communicate with APIM to access them (e.g. via API call). How does IS access those mappings?

- Chathura

On Wed, Jun 28, 2017 at 11:45 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had before with APIM team, resource -> scope mappings will be handled in APIM side and not needed to expose an API for that.

Thanks and Regards

On Wed, Jun 28, 2017 at 11:39 AM, Chathura Ekanayake <[hidden email]> wrote:
Do we store resource -> scope mappings in IS? If so, I think IS has to expose an API to add those. If not, how does IS access those mappings for token validation?

Regards,
Chathura

On Fri, Jun 23, 2017 at 1:23 PM, Bhathiya Jayasekara <[hidden email]> wrote:

On Fri, Jun 23, 2017 at 1:10 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:


On Fri, Jun 23, 2017 at 12:48 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

In error cases shall we send a response like this?

     {
      "error": "invalid_scope_name",
      "error_description": "Scope name cannot contain white spaces"
     }

Currently the error response body is like this. Is it fine to remain as it is or change as you have suggested?
{
    "code": "18005",
    "message": "Conflict",
    "description": "Scope with the name openid already exists in the system. Please use a different scope name."
}

This is fine. 

Thanks,
Bhathiya
 
 
And I think /scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586 is the same as /scopes/{scope_id}.
So we can remove the former.
Yeah. I'll remove that, and if so filtering would be only based on scope name.
 

Thanks,
Bhathiya

On Fri, Jun 23, 2017 at 12:33 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had in [1], there were some database schema changes and endpoint changes were suggested(You can find more details in [1]). Please find the following details on the current database schema changes and endpoints.

Database Schema Change:





Endpoints:

EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate a Scope{"name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}
"HTTP/1.1 201 Created"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}


If name/description is not defined or empty - "HTTP/1.1 400 Bad Request"

If already available scope name - "HTTP/1.1 409 Conflict"
/scopes
GETList Scopes
"HTTP/1.1 200 OK"
[{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}]

"HTTP/1.1 404 Not Found"
An empty array if no scopes exist
/scopes?startIndex=1&count=2GETList Scopes With Pagination
/scopes?filter=name Eq openid
/scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586
GET
List Scopes with Filter





/scopes/names/{scope_name}HEADCheck whether a scope name
exists

"HTTP/1.1 200 OK"

"HTTP/1.1 404 Not Found"

/scopes/{scope_id}GETGet a Scope by Scope ID
"HTTP/1.1 200 OK"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}

"HTTP/1.1 404 Not Found"

DELETEDelete a Scope by
Scope ID

"HTTP/1.1 204 No Content"

PUTUpdate a Scope by
Scope ID
{"name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 200 OK"

If already available scope name -
"HTTP/1.1 409 Conflict"



[1] [IS] [Architecture] Discussion on the REST endpoints and database schema changes for scope bindings which to be included in IS 5.4.0

Thanks and Regards

On Thu, Jun 22, 2017 at 2:56 PM, Isura Karunaratne <[hidden email]> wrote:
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185




--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   0772182255


_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Bhathiya Jayasekara
Hi Chathura,

That validation is done is APIM side. In key validation call, IS returns all scopes of the token, and then APIM validates the scopes using its scope-resource mapping.

Thanks,
Bhathiya

On Wed, Jun 28, 2017 at 11:57 AM, Chathura Ekanayake <[hidden email]> wrote:
Hi Indunil,

I guess IS needs to access resource -> scope mappings for token validation when acting as a key manager. If those mappings are maintained in APIM, IS has to communicate with APIM to access them (e.g. via API call). How does IS access those mappings?

- Chathura

On Wed, Jun 28, 2017 at 11:45 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had before with APIM team, resource -> scope mappings will be handled in APIM side and not needed to expose an API for that.

Thanks and Regards

On Wed, Jun 28, 2017 at 11:39 AM, Chathura Ekanayake <[hidden email]> wrote:
Do we store resource -> scope mappings in IS? If so, I think IS has to expose an API to add those. If not, how does IS access those mappings for token validation?

Regards,
Chathura

On Fri, Jun 23, 2017 at 1:23 PM, Bhathiya Jayasekara <[hidden email]> wrote:

On Fri, Jun 23, 2017 at 1:10 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:


On Fri, Jun 23, 2017 at 12:48 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

In error cases shall we send a response like this?

     {
      "error": "invalid_scope_name",
      "error_description": "Scope name cannot contain white spaces"
     }

Currently the error response body is like this. Is it fine to remain as it is or change as you have suggested?
{
    "code": "18005",
    "message": "Conflict",
    "description": "Scope with the name openid already exists in the system. Please use a different scope name."
}

This is fine. 

Thanks,
Bhathiya
 
 
And I think /scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586 is the same as /scopes/{scope_id}.
So we can remove the former.
Yeah. I'll remove that, and if so filtering would be only based on scope name.
 

Thanks,
Bhathiya

On Fri, Jun 23, 2017 at 12:33 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had in [1], there were some database schema changes and endpoint changes were suggested(You can find more details in [1]). Please find the following details on the current database schema changes and endpoints.

Database Schema Change:





Endpoints:

EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate a Scope{"name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}
"HTTP/1.1 201 Created"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}


If name/description is not defined or empty - "HTTP/1.1 400 Bad Request"

If already available scope name - "HTTP/1.1 409 Conflict"
/scopes
GETList Scopes
"HTTP/1.1 200 OK"
[{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}]

"HTTP/1.1 404 Not Found"
An empty array if no scopes exist
/scopes?startIndex=1&count=2GETList Scopes With Pagination
/scopes?filter=name Eq openid
/scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586
GET
List Scopes with Filter





/scopes/names/{scope_name}HEADCheck whether a scope name
exists

"HTTP/1.1 200 OK"

"HTTP/1.1 404 Not Found"

/scopes/{scope_id}GETGet a Scope by Scope ID
"HTTP/1.1 200 OK"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}

"HTTP/1.1 404 Not Found"

DELETEDelete a Scope by
Scope ID

"HTTP/1.1 204 No Content"

PUTUpdate a Scope by
Scope ID
{"name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 200 OK"

If already available scope name -
"HTTP/1.1 409 Conflict"



[1] [IS] [Architecture] Discussion on the REST endpoints and database schema changes for scope bindings which to be included in IS 5.4.0

Thanks and Regards

On Thu, Jun 22, 2017 at 2:56 PM, Isura Karunaratne <[hidden email]> wrote:
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185




--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255




--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Sagara Gunathunga-2



On Wed, Jun 28, 2017 at 12:00 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Chathura,

That validation is done is APIM side. In key validation call, IS returns all scopes of the token, and then APIM validates the scopes using its scope-resource mapping.

+1 

IMO it's incorrect to perform resource -> scope mapping validation  from IS side because API 'resource' is not a meaningful concept  in IS side.

Thanks !  

Thanks,
Bhathiya

On Wed, Jun 28, 2017 at 11:57 AM, Chathura Ekanayake <[hidden email]> wrote:
Hi Indunil,

I guess IS needs to access resource -> scope mappings for token validation when acting as a key manager. If those mappings are maintained in APIM, IS has to communicate with APIM to access them (e.g. via API call). How does IS access those mappings?

- Chathura

On Wed, Jun 28, 2017 at 11:45 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had before with APIM team, resource -> scope mappings will be handled in APIM side and not needed to expose an API for that.

Thanks and Regards

On Wed, Jun 28, 2017 at 11:39 AM, Chathura Ekanayake <[hidden email]> wrote:
Do we store resource -> scope mappings in IS? If so, I think IS has to expose an API to add those. If not, how does IS access those mappings for token validation?

Regards,
Chathura

On Fri, Jun 23, 2017 at 1:23 PM, Bhathiya Jayasekara <[hidden email]> wrote:

On Fri, Jun 23, 2017 at 1:10 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:


On Fri, Jun 23, 2017 at 12:48 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

In error cases shall we send a response like this?

     {
      "error": "invalid_scope_name",
      "error_description": "Scope name cannot contain white spaces"
     }

Currently the error response body is like this. Is it fine to remain as it is or change as you have suggested?
{
    "code": "18005",
    "message": "Conflict",
    "description": "Scope with the name openid already exists in the system. Please use a different scope name."
}

This is fine. 

Thanks,
Bhathiya
 
 
And I think /scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586 is the same as /scopes/{scope_id}.
So we can remove the former.
Yeah. I'll remove that, and if so filtering would be only based on scope name.
 

Thanks,
Bhathiya

On Fri, Jun 23, 2017 at 12:33 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had in [1], there were some database schema changes and endpoint changes were suggested(You can find more details in [1]). Please find the following details on the current database schema changes and endpoints.

Database Schema Change:





Endpoints:

EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate a Scope{"name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}
"HTTP/1.1 201 Created"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}


If name/description is not defined or empty - "HTTP/1.1 400 Bad Request"

If already available scope name - "HTTP/1.1 409 Conflict"
/scopes
GETList Scopes
"HTTP/1.1 200 OK"
[{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}]

"HTTP/1.1 404 Not Found"
An empty array if no scopes exist
/scopes?startIndex=1&count=2GETList Scopes With Pagination
/scopes?filter=name Eq openid
/scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586
GET
List Scopes with Filter





/scopes/names/{scope_name}HEADCheck whether a scope name
exists

"HTTP/1.1 200 OK"

"HTTP/1.1 404 Not Found"

/scopes/{scope_id}GETGet a Scope by Scope ID
"HTTP/1.1 200 OK"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}

"HTTP/1.1 404 Not Found"

DELETEDelete a Scope by
Scope ID

"HTTP/1.1 204 No Content"

PUTUpdate a Scope by
Scope ID
{"name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 200 OK"

If already available scope name -
"HTTP/1.1 409 Conflict"



[1] [IS] [Architecture] Discussion on the REST endpoints and database schema changes for scope bindings which to be included in IS 5.4.0

Thanks and Regards

On Thu, Jun 22, 2017 at 2:56 PM, Isura Karunaratne <[hidden email]> wrote:
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185




--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255




--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com


_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev
Reply | Threaded
Open this post in threaded view
|

Re: [Architecture] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Bhathiya Jayasekara
Hi Chathura,

By APIM I actually meant the Gateway. 

We pull resource-scope mapping data from APIM core to gateway. Then we do that validation inside the Ballerina handler which handles authentication.

Thanks,
Bhathiya   

On Wed, Jun 28, 2017 at 12:19 PM, Chathura Ekanayake <[hidden email]> wrote:
@Sagara: Yes, I was just thinking how/where the validation is done.

@Bhathiya: So the gateway calls APIM for key validation, without directly calling IS?

On Wed, Jun 28, 2017 at 12:05 PM, Sagara Gunathunga <[hidden email]> wrote:



On Wed, Jun 28, 2017 at 12:00 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Chathura,

That validation is done is APIM side. In key validation call, IS returns all scopes of the token, and then APIM validates the scopes using its scope-resource mapping.

+1 

IMO it's incorrect to perform resource -> scope mapping validation  from IS side because API 'resource' is not a meaningful concept  in IS side.

Thanks !  

Thanks,
Bhathiya

On Wed, Jun 28, 2017 at 11:57 AM, Chathura Ekanayake <[hidden email]> wrote:
Hi Indunil,

I guess IS needs to access resource -> scope mappings for token validation when acting as a key manager. If those mappings are maintained in APIM, IS has to communicate with APIM to access them (e.g. via API call). How does IS access those mappings?

- Chathura

On Wed, Jun 28, 2017 at 11:45 AM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had before with APIM team, resource -> scope mappings will be handled in APIM side and not needed to expose an API for that.

Thanks and Regards

On Wed, Jun 28, 2017 at 11:39 AM, Chathura Ekanayake <[hidden email]> wrote:
Do we store resource -> scope mappings in IS? If so, I think IS has to expose an API to add those. If not, how does IS access those mappings for token validation?

Regards,
Chathura

On Fri, Jun 23, 2017 at 1:23 PM, Bhathiya Jayasekara <[hidden email]> wrote:

On Fri, Jun 23, 2017 at 1:10 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:


On Fri, Jun 23, 2017 at 12:48 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

In error cases shall we send a response like this?

     {
      "error": "invalid_scope_name",
      "error_description": "Scope name cannot contain white spaces"
     }

Currently the error response body is like this. Is it fine to remain as it is or change as you have suggested?
{
    "code": "18005",
    "message": "Conflict",
    "description": "Scope with the name openid already exists in the system. Please use a different scope name."
}

This is fine. 

Thanks,
Bhathiya
 
 
And I think /scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586 is the same as /scopes/{scope_id}.
So we can remove the former.
Yeah. I'll remove that, and if so filtering would be only based on scope name.
 

Thanks,
Bhathiya

On Fri, Jun 23, 2017 at 12:33 PM, Indunil Upeksha Rathnayake <[hidden email]> wrote:
Hi,

As per the discussion we had in [1], there were some database schema changes and endpoint changes were suggested(You can find more details in [1]). Please find the following details on the current database schema changes and endpoints.

Database Schema Change:





Endpoints:

EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate a Scope{"name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}
"HTTP/1.1 201 Created"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": ["role1", "role2"]}


If name/description is not defined or empty - "HTTP/1.1 400 Bad Request"

If already available scope name - "HTTP/1.1 409 Conflict"
/scopes
GETList Scopes
"HTTP/1.1 200 OK"
[{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}]

"HTTP/1.1 404 Not Found"
An empty array if no scopes exist
/scopes?startIndex=1&count=2GETList Scopes With Pagination
/scopes?filter=name Eq openid
/scopes?filter=id Eq 72fa98a0-387b-4ce5-9a17-342727415586
GET
List Scopes with Filter





/scopes/names/{scope_name}HEADCheck whether a scope name
exists

"HTTP/1.1 200 OK"

"HTTP/1.1 404 Not Found"

/scopes/{scope_id}GETGet a Scope by Scope ID
"HTTP/1.1 200 OK"
{"id": "1234", "name": "openid", "description": "openid scope", "bindings": []}

"HTTP/1.1 404 Not Found"

DELETEDelete a Scope by
Scope ID

"HTTP/1.1 204 No Content"

PUTUpdate a Scope by
Scope ID
{"name": "openid", "description": "openid scope", "bindings": ["role3", "role4"]}"HTTP/1.1 200 OK"

If already available scope name -
"HTTP/1.1 409 Conflict"



[1] [IS] [Architecture] Discussion on the REST endpoints and database schema changes for scope bindings which to be included in IS 5.4.0

Thanks and Regards

On Thu, Jun 22, 2017 at 2:56 PM, Isura Karunaratne <[hidden email]> wrote:
On Wed, Jun 14, 2017 at 11:06 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

A few more details.

On Wed, Jun 14, 2017 at 10:52 PM, Bhathiya Jayasekara <[hidden email]> wrote:
Hi Indunil,

Please see my comments inline.

On Wed, Jun 14, 2017 at 7:28 PM, Indunil Upeksha Rathnayake <[hidden email]> 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.


EndpointMethodUsageRequest BodyResponse
/scopesPOSTCreate 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.  
 
 

DELETEDelete Scopes["key1", "key2"]"HTTP/1.1 201 Deleted"

PUTUpdate 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.)

 

 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?

+1. 
@Indunil

Did we consider this when implementing delete scopes?

Thanks
Isura.  
 

Thanks,
Bhathiya
 
 
/scopes?filter=maxResults+Eq+100GETGet all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}]

/scopes/by-bindingsGETGet 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/keysGETGet all the available
Scope Keys

["key1", "key2"]

/scopes/keys/by-bindingsGETGet Scope keys
by Binding/s
{"bindings": ["role1", "role2"]}["key1", "key2"]

We can do the same here.

/scopes/keys?bindings=role1,role2
 

/scopes/{scope_key}GETGet a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope", "bindings": []}

DELETEDelete a Scope by
Scope Key

"HTTP/1.1 201 Deleted"

PUTUpdate 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 <[hidden email]> wrote:

On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <[hidden email]> 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-oauth/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    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255
--
Nuwan Dias

Software Architect - WSO2, Inc. http://wso2.com
Phone : <a href="tel:+94%2077%20777%205729" value="+94777775729" target="_blank">+94 777 775 729



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Isura Dilhara Karunaratne
Senior Software Engineer | WSO2
Mob : <a href="tel:+94%2077%20225%204810" value="+94772254810" target="_blank">+94 772 254 810






--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255



--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185




--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email    [hidden email]
Mobile   <a href="tel:077%20218%202255" value="+94772182255" target="_blank">0772182255




--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: <a href="tel:+94%2071%20547%208185" value="+94715478185" target="_blank">+94715478185



--
Sagara Gunathunga

Associate Director / Architect; WSO2, Inc.;  http://wso2.com
V.P Apache Web Services;    http://ws.apache.org/
Linkedin; http://www.linkedin.com/in/ssagara
Blog ;  http://ssagara.blogspot.com





--
Bhathiya Jayasekara
Associate Technical Lead,
WSO2 inc., http://wso2.com

Phone: +94715478185

_______________________________________________
Dev mailing list
[hidden email]
http://wso2.org/cgi-bin/mailman/listinfo/dev