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 [email protected]
Mobile 0772182255
_______________________________________________
Architecture mailing list
[email protected]
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
