[Dev] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

classic Classic list List threaded Threaded
3 messages Options
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

[Dev] [IS] Features to be included in IS 5.4.0 which required for APIM 3.0

Indunil Upeksha Rathnayake
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?
  • 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

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Indunil Upeksha Rathnayake
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

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

api.identity.oauth2.scope.endpoint.yaml (24K) Download Attachment
Reply | Threaded
Open this post in threaded view
|  
Report Content as Inappropriate

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

Bhathiya Jayasekara
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. 
 

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.)
 
/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: +94715478185

_______________________________________________
Architecture mailing list
[hidden email]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
Loading...