IS 7.0 Authorization Server Support

[senthuran16]

Problem

Currently when using IS7 as a Key Manager with APIM 4.3.0, we don't support scopes. We don't create Scope-to-Role mapping in IS7. We will only create Resource-to-Scope mapping from APIM side. The relevant Scope-to-Role mapping should have been created in IS7, similar to the example shown in the following diagram:

Diagram1

This limitation is due to the new Scopes & Roles model introduced in IS 7.

As shown in Diagram 1 above, we needed to create the necessary role via the IS 7 Console UI, and the scope binding (via Scopes REST API)

Solution

We will have to use the REST APIs provided by IS7 [1] to create the necessary role & scope mappings when creating a Resource-to-Scope mapping from APIM side.

[1] https://is.docs.wso2.com/en/latest/apis/roles-v2-rest-api/

Affected Component

APIM

Version

4.3.0

Implementation

No response

Related Issues

No response

Suggested Labels

No response

[senthuran16]

Hi all,

Earlier, I tested with the old scope model - as depicted in the diagram in this issue's description [1]. The following properties were enabled in IS 7.0's repository/conf/deployment.toml:

[oauth.global_rbac_scope_issuer]
enable=true

[oauth.global_scope_validators.role_based_scope_issuer]
enable=true

Since we'll have to use the new permission model of IS 7.0 to do the same thing, I tested by manually creating the artifacts that go on par with IS 7.0's new permission model. (I removed the above two properties as well)

Based on the above diagram, when the user pizzaguy16 (who has the role pizzaguy16_2d9509e4-ebbb-4cdb-9e28-...) requests a token with the scope pizzaguy_scope16 (which is required to invoke the Pizzashack API 's GET /menu resource), pizzaguy16 will get that scope in the issued token (since pizzaguy16 possess the pizzaguy16_2d9509e4-ebbb-4cdb-9e28-... role).

I tested the above, and it's working as expected. Next step is to check the APIs and see a way to automate these artifact creations.

[1] #2937 (comment)

[senthuran16]

Hi all,

I did the following sequence of events when creating a role & scope in APIM, and then the corresponding role & scope in IS 7.0 (created them manually)

1. [APIM] Created User pizzaguy18 & pizzaguy_role18. Assigned pizzaguy_role18 to pizzaguy18.
2. [APIM] In the Pizzashack API's GET /menu resource, added the local scope pizzaguy_scope18 with role pizzaguy_role18.
3. [IS] Created the API Resource Pizzashack API 18 - with a permission or scope pizzaguy_scope18.
4. [IS] Created the role pizzaguy_role18 with Organization audience.
5. [IS] Created the user pizzaguy18 and provided the user with the role pizzaguy_role18.
6. [IS] We already have the application. Modified the Role Audience to 'Organization' (since we don't create the application via the IS7 connector with audience=Organization).
7. Authorized that application with all scopes of API ResourcePizzashack_ API 18 (with Policy = RBAC).

Now, when user pizzaguy18 uses the consumerKey & secret of the application, uses pizzaguy18's credentials, and requests for a token with scope pizzaguy_scope18, the scope is given in the token.

A caveat

In step 7 above, we authorize an application against an API resource. Since an application is not intended to be used by only one API, should we authorize all applications against all API Resources?
We will discuss on this further.

[senthuran16]

Hi all,

One possible approach we discussed with @tharindu1st to maintain a list of scopes was, to have a common API Resource for all the scopes that are created by the IS7 Connector (eg: _APIM_IS7_CONNECTOR_API_RESOURCE). Although the necessity of explicitly adding an organization role to an application has been removed in wso2is-7.0.0.25, we still have to explicitly allow each scope of API Resource in an application. Without doing this, a user won't be able to request a scope using that application.

I tried adding only the API Resource under API Authorization of the application (without any scope), but it behaves as "no scopes of the API Resource" - and not as "all scopes of the API Resource". (Tried this with Requires authorization turned off in the API Resource as well).

We won't be able to add "all scopes of an API resource" everytime we create an application, because once a new scope is created, we will have to revisit every application that we created, and add that new scope to the list of 'authorized scopes' (Since we will be creating applications in IS7 continuously, and scopes continuously as well).

We will have to check whether we can avoid listing down each scope of the API resource under the application, so that, once we create an application, we just allow the API resource, not each scope individually.

[senthuran16]

Hi all,

Currently I'm proceeding with the approach of using an API Resource which will contain all the scopes we create from the APIM IS7 Connector. According to IS7 migration model [1], we could use the API Resource name User-defined-oauth2-resource as well.

We had a discussion with the IS team regarding the need of explicitly authorizing scopes under API Resource. We requested them for a way, where we should be able to allow IS7 OAuth2 applications to request scopes without being authorized with any API Resource.

For now, the above shortcoming is not a blocker for the implementation. I'm manually authorizing the application to allow access to all those scopes of that API Resource when testing a subscription.

Even though it's not a blocker for implementation, as we discussed, we can't release an update to the connector (with the improvement) without the above concern being addressed.

[1] https://github.com/wso2-enterprise/migration-docs/blob/main/identity-server/migration-docs/is-7.0.0/migrating-authorization-model.md

[senthuran16]

Hi all,
As per our latest discussions, I have done the implementation as described in my above comment [1] (i.e: using a API Resource to contain all the scopes). We'll be parking this task and waiting for the IS team to provide the fix of not requiring applications to be authorized with the scopes of the API Resource. After they provide this fix, we will resume and we will be taking one week and do testing.

[1] #2937 (comment)

[senthuran16]

Hi all,

The IS team has provided us a preQA with their changes.

I'm resuming this task, and starting to test it & improve the code. Will keep this thread updated as I progress.

[senthuran16]

Hi all,

So far, I have tested the following:

• Create local scope - which doesn't exist in IS, from APIM (new scope will be created in IS)
• Create a local scope - which already exists in IS, from APIM
• Test client_credentials grant type
• Test password grant type

When testing the password grant type, noticed that the applications we create via the connector are created with Role Audience = Application, and due to that users with the relevant role can't obtain the corresponding scope. Will check about the solution and fix it.

I'll keep this thread updated as I perform more tests & progress.

[senthuran16]

Hi all,

I have tested the following flows:

• Create new scope from APIM (new scope will be created in IS)
  • Local & shared scopes
• Create a scope & role that’s already existing in IS
  • Local & shared scopes
• Test with client_credentials grant type
  • Local & shared scopes
• Test with password grant type
  • Local & shared scopes

The system-wide property that was introduced from IS side - to make OAuth2 applications in IS7 not to be authorized with API Resources & Scopes before requesting scopes - is working as expected.

Upon our testing, we noticed the following shortcomings, and we will need the following fixes from the IS team.

• “Role audience” of applications cannot be controlled in the IS7 OAuth app DCR call.
  • We need to set role audience to "organization", otherwise, password grant is not working as expected. We will need an ext attribute for this. Like we discussed in our earlier conversations, using the Application Management REST APIs will not be feasible since it's an additional API call per application key generation.
• In the IS7 API Resource REST APIs, we don't have a resource to update existing scopes (permissions).
  • This makes it not possible to update a scope. Deleting an IS7 scope & adding again is not feasible, since roles are already assigned with these scopes (permissions).

We have requested the above from the IS team, and they agreed to deliver us the fixes by this week. We'll have to modify our code according to these, so it's an implementation blocker for us. For the moment, I'll be improving the code, and will be testing other applicable flows while waiting for the fix from the IS team.

[senthuran16]

Hi all,

I have sent the PR for this feature at [1]. The IS team has provided the fixes requested at [2], and they work as expected. I will get the PR reviewed, and provide an update here.

[1] wso2-extensions/apim-km-wso2is#147
[2] #2937 (comment)

[senthuran16]

Hi all,

The PRs for this feature [1][2] have been merged. APIM IS7 KM connector 2.0.3 [3] has been released with RBAC support for IS7.

[1] wso2-extensions/apim-km-wso2is#147
[2] wso2-extensions/apim-km-wso2is#148
[3] https://github.com/wso2-extensions/apim-km-wso2is/releases/tag/v2.0.3

Thanks,
Senthuran.