Hi, Thanks all of your valuable feedbacks. Currently we are implementing following REST endpoints. We have modeled the the rest API using swagger and you can find the attached swagger definition as well. Really appreciate your comments and suggestions on the specified endpoints, please mention if there are other required endpoints.
Endpoint Method Usage Request Body Response
/scopes POST Create Scopes [{"key": "openid", "name": "openid",
"description": "openid scope", "bindings": ["role1", "role2"]}] "HTTP/1.1
201 Created"
DELETE Delete Scopes ["key1", "key2"] "HTTP/1.1 201 Deleted"
PUT Update Scopes [{"key": "openid", "name": "openid", "description":
"openid scope", "bindings": ["role3"]}] "HTTP/1.1 201 Updated"
/scopes?filter=maxResults+Eq+100 GET Get all available Scopes
[{"key": "openid", "name": "openid", "description": "openid scope",
"bindings": []}]
/scopes/by-bindings GET Get Scopes by Binding/s {"bindings": ["role1",
"role2"]} [{"key": "openid", "name": "openid", "description": "openid
scope", "bindings": ["role1", "role2"]}]
/scopes/keys GET Get all the available
Scope Keys
["key1", "key2"]
/scopes/keys/by-bindings GET Get Scope keys
by Binding/s {"bindings": ["role1", "role2"]} ["key1", "key2"]
/scopes/{scope_key} GET Get a Scope by Scope Key
{"key": "openid", "name": "openid", "description": "openid scope",
"bindings": []}
DELETE Delete a Scope by
Scope Key
"HTTP/1.1 201 Deleted"
PUT Update a Scope by
Scope Key {"key": "openid", "name": "openid", "description": "openid
scope", "bindings": ["role3", "role4"]} "HTTP/1.1 201 Updated"
@Nuwan: We have a suggestion to modified the database schema as follows to
properly store bindings (considering the performance issues in using comma
separated values and renaming the "ROLES" field to a generic name), but
need to discuss about this and finalize.
Appreciate your comments and suggestions and I will arrange a meeting
tomorrow to have a further discussion on this.
Thanks and Regards
On Mon, Jun 12, 2017 at 2:53 AM, Nuwan Dias <[email protected]> wrote:
>
> On Fri, Jun 9, 2017 at 5:46 AM Indunil Upeksha Rathnayake <
> [email protected]> wrote:
>
>> Hi,
>>
>> We are currently working on implementing following features which are
>> needed for APIM 3.0. You can find the initial discussion details in [1].
>>
>> 1. Sign UserInfo JWT response
>> 2. Scope registration and Scope binding
>> 3. DCRM
>>
>>
>> *Sign UserInfo JWT response:*
>> JWT user info response signing implementation is in [1].
>>
>> Currently in APIM, there is a key manager global wise configuration to
>> configure needed claims which needed to be send in user info response. We
>> need to consider, when no SP wise requested claims are configured as in
>> APIM, whether we need to send all the claims bound for a specific scope in
>> oidc-scope-config.xml.
>> Currently in IS, we are sending only those claims which are common in
>> both OIDC scope config and SP claim configuration (ie. intersection of
>> claim in both these configs).
>>
>> *Shall we send all the bounded claims if requested claims are not
>> defined?*
>>
>> *Scope registration and Scope binding:*
>> New endpoints will be exposed in IS 5.4.0 to handle Scope register, bind,
>> update, delete, list etc.
>>
>> As per the current implementation of APIM and IoT, following things can
>> be noticed and have following concerns.
>>
>> - Scope can be bound with roles or permissions - Uses scope to role
>> binding in APIM and uses scope to permission binding in IoT.
>>
>>
>> - Both of the above bindings are stored in "IDN_OAUTH2_SCOPE" table
>> where roles and permissions both are stored as a comma separated string in
>> same column named "ROLES". AFAIU, there is no indication with a prefix in
>> scope registration, where to separate the two bindings. *There can be
>> other bindings which will be added in future, isn't it better to renamed
>> the field as "BINDINGS"? There can be a situation where both set of roles
>> and permissions are bound to a scope?*
>>
>> Its better to rename but please note that this is a minor version upgrade
> and hence it's better to avoid schema changes.
>
>>
>> -
>>
>>
>> - In scope validation, currently there are validators for role based
>> and permission based. The corresponding validator will be selected based
>> on
>> the prefix (ex: Permission based scope validator only validates the scope
>> which are having "perm" as the prefix of the scopes) and if scope prefix
>> is
>> not defined, those will directly go to the default role based scope
>> validator. *How this prefix has to be considered and validated in
>> scope registration with the bindings?*
>>
>>
>> - In scope registration, AFAIU, scope key and name are the essential
>> details to be included. *What is the difference of theses and where
>> these values will be used? scope key is the unique value which need to be
>> considered in scope binding?*
>>
>>
>> 1. Scope Register and Bind
>> There can be following scenarios a scope can be registered and bound.
>> CreateScope - scope key, scope name, roles
>> CreateScope - scope key, scope name, permissions
>> CreateScope - scope key, scope name
>>
>> So that we have implemented "/api/identity/oauth2/scope/v0.9/registerScope"
>> endpoint to register set of scopes with the bindings. "key" and "name"
>> cannot be null and bindings(added a generic property rather adding two
>> properties for roles and permissions) will be stored as comma separated
>> values in IDN_OAUTH2_SCOPE table.
>>
>>> {"scope": [{"key": "openid", "name": "openid", "description": "openid
>>> scope", "bindings": ["role1", "role2"]}]}
>>>
>>
>> 2. Scope Update
>> "/updateScope" endpoint to update a set of scopes with the bindings which
>> need to be added and deleted.
>>
>>> {"scope": [{"key": "openid", "addedBindings": ["role3"],
>>> "deletedBindings": ["role2"]}]}
>>>
>>
>> 3. Scope Delete
>> "/deleteScope" endpoint to delete a set of scopes.
>>
>>> {"scope": ["scope_key_1", "scope_key_2"]}
>>>
>>
>> 4. Scope List
>> Endpoints for following scenarios.
>> 1. Get scope by key
>> 2. Get scope key list by role/s - given a role or role list, return the
>> list of scope keys that includes all of those roles
>> 3. Get scope key list by permission/s - given a permission or permission
>> list, return the list of scope keys that includes all of those permissions
>> 4. Get scopes by role/s - for a given role or role list, return the list
>> of scopes that includes all of those roles with all the details
>> 5. Get scopes by permission/s - for a given permission or permission
>> list, return the list of scopes that includes all of those permissions with
>> all the details
>> 6. Get all the available scope keys
>> 7. Get all the available scopes with their description and allocated
>> roles/permissions
>>
>> Appreciate your comments and suggestions on this.
>>
>>
>> *DCRM:*
>> Abilashini is working on this as a GSoC project and discussion is in [3].
>>
>>
>> [1] Discussion on features which required for APIM to be incl... @ Tue
>> May 30, 2017 10:30am - 12pm (IST) (WSO2 Engineering Group)
>> [2] https://github.com/wso2-extensions/identity-inbound-
>> auth-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 [email protected]
>> Mobile 0772182255
>>
> --
> Nuwan Dias
>
> Software Architect - WSO2, Inc. http://wso2.com
> email : [email protected]
> Phone : +94 777 775 729 <+94%2077%20777%205729>
>
--
Indunil Upeksha Rathnayake
Software Engineer | WSO2 Inc
Email [email protected]
Mobile 0772182255
api.identity.oauth2.scope.endpoint.yaml
Description: application/yaml
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
