Re: [Architecture] [APIM] Support Global OAuth2 Scopes and Attaching Multiple Scopes per API Resource

[Amila De Silva]

A couple of other points needing the opinion of a wider audience are;

1. Whether only to support Global scopes in future releases and convert all
per API scopes to Global scopes.

One of the points raised during an internal discussion was that, per API
scopes will get obsolete with the introduction of Global scopes, since a
global scope can be used in the place of a per API scope. If an API
Provider needs to use a completely different scope (than the ones already
available in the system), they can still define it as a Global scope and
assign it to the API/resource. The new scope will be a shared one and can
be used for other APIs by different API developers.
Unless an API Developer needs to restrict the usage of several scopes to a
few selected APIs, Global scopes can replace per API scopes.


2. While creating an API using the Swagger, only doing the scope
assignments without creating any new scope.

Suggestion is to use scopes defined in the swagger only to do scope to
resource assignment. If the scopes are already available in the System,
those will be assigned to the Resources as specified by the Swagger. If
not, the API will be created without creating any scopes. This would help
removing scope to role mapping from swagger and would also eliminate the
need of identifying Global and Per-API scopes differently. But a different
configuration is needed to keep that information while exporting/importing
APIs. The idea is to have a clean Swagger while moving all wso2 specific
configurations to a different file.


On Mon, Jan 20, 2020 at 11:50 AM Dushani Wellappili 
wrote:

> Hi all,
>
> According to the recent discussions we've had, we have modified the
> initial DB design as follows.
>
>- Remove the FK constraint on SCOPE_ID, as it would be easy when
>decoupling API-M from IS components in the future.
>- Add a UUID for Global Scopes to support REST APIs
>
> AM_GLOBAL_SCOPE
>  SCOPE_ID INTEGER NOT NULL,
>  TENANT_ID INTEGER DEFAULT -1,
>  UUID VARCHAR (256)
>
> In addition, the following points are highlighted which we need to
> discuss further.
>
>- The management of scopes can be done in the Publisher Portal and it
>would make more sense if move it to the same UI view of APIs as scopes are
>straightly attached to APIs.
>- With the above design of global scopes, there will be no way to
>differentiate global and local scopes from the swagger. Hence, if the
>global scope - role bindings are updated after publishing the API, the role
>changes will not be reflected when validating API requests using Basic
>Auth. In such cases, we need to republish the APIs.
>- Currently, we do not support adding local scopes with the same name
>for different APIs. Hence, other than using local scopes to restrict the
>use of the same for other APIs, there would not be any difference between
>local and global scopes.
>- If we are removing local scope support, we need to migrate the
>existing local scopes of previous versions to global. In migration, we need
>to add the existing scope_ids and tenant_ids to the AM_GLOBAL_SCOPE table
>with new UUIDs.
>
>
> Thanks
>
> *Dushani Wellappili*
> Senior Software Engineer - WSO2
>
> Email : dusha...@wso2.com
> Mobile : +94779367571
> Web : https://wso2.com/
>
>
>
>
> On Mon, Jan 20, 2020 at 11:19 AM Dushani Wellappili 
> wrote:
>
>> Hi all,
>>
>> This is to provide an example use-case of supporting global scopes when
>> an application is using multiple APIs and it supports functionalities for
>> users with different types of permissions. There are two sets of users
>> where the one set will only have view-only permissions and another set will
>> have both read and edit permissions.
>>
>> For example, assume an application is using both API A and B. API A has 2
>> operations ( /a GET, /a POST) and similarly API B has 2 operations ( /b
>> GET, /b POST). The users of set 1 only have read permission and set 2 have
>> both read-write permissions. The permissions are given by assigning roles.
>>
>> set 1 user - role 1 (read-only role)
>> set 2 users - role 2 (read-write role)
>>
>> The users of set 1 need to be provided access for both (/a GET) and (/b
>> GET). The users of set 2 need to be provided access for all the 4
>> operations (/a GET, /a POST, /b GET, /b POST) of API A and API B.
>>
>> With the current functionality of WSO2 API-M local scopes, this can be
>> achieved by creating 2 local scopes (view-scope, edit-scope) for each API,
>> and define role bindings of the users based on the permissions they
>> have. Then, assign them to the API operations.
>>
>> *API A*
>> view-scopeA - role1, role2
>> edit-scopeA - role2
>>
>> /a GET view-scopeA
>> /a POST edit-scopeA
>>
>> *API B*
>> view-scopeB - role1, role2
>> edit-scopeB - role2
>>
>> /b GET view-scopeB
>> /b POST edit-scopeB
>>
>> The main limitation of the above way is that we need to create 4 scopes
>> separately with 4 unique scope keys duplicati

Re: [Architecture] [APIM] Support Global OAuth2 Scopes and Attaching Multiple Scopes per API Resource

[Amila De Silva]

Hi Sanjeewa,
How about having a separate permission for creating/managing Scopes and
assigning it to a selected few API Creators? If the Global scope creation
becomes a simple process may be we can have it under Publisher UI or if it
involves retaining some of the functionality Per-API-Scopes had (like being
able to select a few APIs where a particular scope can be used with) then
we can have a different UI under Admin portal. But regardless of where it
resides, having a permission, would give some level of flexibility, with
determining who can create/manage the scopes.


On Mon, Jan 20, 2020 at 11:53 AM Sanjeewa Malalgoda 
wrote:

> Hi All,
> Creating global scope is always admin task or should we let publishers to
> initiate creating global scopes. Asking this because most of the time its
> developers who create scopes and sometimes they may think this scope can
> use widely. Isn't it a case we should consider. Also need to think about
> scenarios related to basic auth as role assignment change for global role
> does not reflect to API level metadata stored in gateway.
>
> Thanks,
> sanjeewa.
>
> On Mon, Jan 20, 2020 at 11:50 AM Dushani Wellappili 
> wrote:
>
>> Hi all,
>>
>> According to the recent discussions we've had, we have modified the
>> initial DB design as follows.
>>
>>- Remove the FK constraint on SCOPE_ID, as it would be easy when
>>decoupling API-M from IS components in the future.
>>- Add a UUID for Global Scopes to support REST APIs
>>
>> AM_GLOBAL_SCOPE
>>  SCOPE_ID INTEGER NOT NULL,
>>  TENANT_ID INTEGER DEFAULT -1,
>>  UUID VARCHAR (256)
>>
>> In addition, the following points are highlighted which we need to
>> discuss further.
>>
>>- The management of scopes can be done in the Publisher Portal and it
>>would make more sense if move it to the same UI view of APIs as scopes are
>>straightly attached to APIs.
>>- With the above design of global scopes, there will be no way to
>>differentiate global and local scopes from the swagger. Hence, if the
>>global scope - role bindings are updated after publishing the API, the 
>> role
>>changes will not be reflected when validating API requests using Basic
>>Auth. In such cases, we need to republish the APIs.
>>- Currently, we do not support adding local scopes with the same name
>>for different APIs. Hence, other than using local scopes to restrict the
>>use of the same for other APIs, there would not be any difference between
>>local and global scopes.
>>- If we are removing local scope support, we need to migrate the
>>existing local scopes of previous versions to global. In migration, we 
>> need
>>to add the existing scope_ids and tenant_ids to the AM_GLOBAL_SCOPE table
>>with new UUIDs.
>>
>>
>> Thanks
>>
>> *Dushani Wellappili*
>> Senior Software Engineer - WSO2
>>
>> Email : dusha...@wso2.com
>> Mobile : +94779367571
>> Web : https://wso2.com/
>>
>>
>>
>>
>> On Mon, Jan 20, 2020 at 11:19 AM Dushani Wellappili 
>> wrote:
>>
>>> Hi all,
>>>
>>> This is to provide an example use-case of supporting global scopes when
>>> an application is using multiple APIs and it supports functionalities for
>>> users with different types of permissions. There are two sets of users
>>> where the one set will only have view-only permissions and another set will
>>> have both read and edit permissions.
>>>
>>> For example, assume an application is using both API A and B. API A has
>>> 2 operations ( /a GET, /a POST) and similarly API B has 2 operations ( /b
>>> GET, /b POST). The users of set 1 only have read permission and set 2 have
>>> both read-write permissions. The permissions are given by assigning roles.
>>>
>>> set 1 user - role 1 (read-only role)
>>> set 2 users - role 2 (read-write role)
>>>
>>> The users of set 1 need to be provided access for both (/a GET) and (/b
>>> GET). The users of set 2 need to be provided access for all the 4
>>> operations (/a GET, /a POST, /b GET, /b POST) of API A and API B.
>>>
>>> With the current functionality of WSO2 API-M local scopes, this can be
>>> achieved by creating 2 local scopes (view-scope, edit-scope) for each API,
>>> and define role bindings of the users based on the permissions they
>>> have. Then, assign them to the API operations.
>>>
>>> *API A*
>>> view-scopeA - role1, role2
>>> edit-scopeA - role2
>>>
>>> /a GET view-scopeA
>>> /a POST edit-scopeA
>>>
>>> *API B*
>>> view-scopeB - role1, role2
>>> edit-scopeB - role2
>>>
>>> /b GET view-scopeB
>>> /b POST edit-scopeB
>>>
>>> The main limitation of the above way is that we need to create 4 scopes
>>> separately with 4 unique scope keys duplicating the scope-role bindings.
>>> Hence, for such cases, it is ideal to have the capability to define the
>>> scope-role bindings globally and reuse them in the API operations. So the
>>> API developers can restrict access for the API operations of the APIs
>>> globally.
>>>
>>> So there will be only two scopes which need

Re: [Architecture] [APIM] Support Global OAuth2 Scopes and Attaching Multiple Scopes per API Resource

[Sanjeewa Malalgoda]

Hi All,
Creating global scope is always admin task or should we let publishers to
initiate creating global scopes. Asking this because most of the time its
developers who create scopes and sometimes they may think this scope can
use widely. Isn't it a case we should consider. Also need to think about
scenarios related to basic auth as role assignment change for global role
does not reflect to API level metadata stored in gateway.

Thanks,
sanjeewa.

On Mon, Jan 20, 2020 at 11:50 AM Dushani Wellappili 
wrote:

> Hi all,
>
> According to the recent discussions we've had, we have modified the
> initial DB design as follows.
>
>- Remove the FK constraint on SCOPE_ID, as it would be easy when
>decoupling API-M from IS components in the future.
>- Add a UUID for Global Scopes to support REST APIs
>
> AM_GLOBAL_SCOPE
>  SCOPE_ID INTEGER NOT NULL,
>  TENANT_ID INTEGER DEFAULT -1,
>  UUID VARCHAR (256)
>
> In addition, the following points are highlighted which we need to
> discuss further.
>
>- The management of scopes can be done in the Publisher Portal and it
>would make more sense if move it to the same UI view of APIs as scopes are
>straightly attached to APIs.
>- With the above design of global scopes, there will be no way to
>differentiate global and local scopes from the swagger. Hence, if the
>global scope - role bindings are updated after publishing the API, the role
>changes will not be reflected when validating API requests using Basic
>Auth. In such cases, we need to republish the APIs.
>- Currently, we do not support adding local scopes with the same name
>for different APIs. Hence, other than using local scopes to restrict the
>use of the same for other APIs, there would not be any difference between
>local and global scopes.
>- If we are removing local scope support, we need to migrate the
>existing local scopes of previous versions to global. In migration, we need
>to add the existing scope_ids and tenant_ids to the AM_GLOBAL_SCOPE table
>with new UUIDs.
>
>
> Thanks
>
> *Dushani Wellappili*
> Senior Software Engineer - WSO2
>
> Email : dusha...@wso2.com
> Mobile : +94779367571
> Web : https://wso2.com/
>
>
>
>
> On Mon, Jan 20, 2020 at 11:19 AM Dushani Wellappili 
> wrote:
>
>> Hi all,
>>
>> This is to provide an example use-case of supporting global scopes when
>> an application is using multiple APIs and it supports functionalities for
>> users with different types of permissions. There are two sets of users
>> where the one set will only have view-only permissions and another set will
>> have both read and edit permissions.
>>
>> For example, assume an application is using both API A and B. API A has 2
>> operations ( /a GET, /a POST) and similarly API B has 2 operations ( /b
>> GET, /b POST). The users of set 1 only have read permission and set 2 have
>> both read-write permissions. The permissions are given by assigning roles.
>>
>> set 1 user - role 1 (read-only role)
>> set 2 users - role 2 (read-write role)
>>
>> The users of set 1 need to be provided access for both (/a GET) and (/b
>> GET). The users of set 2 need to be provided access for all the 4
>> operations (/a GET, /a POST, /b GET, /b POST) of API A and API B.
>>
>> With the current functionality of WSO2 API-M local scopes, this can be
>> achieved by creating 2 local scopes (view-scope, edit-scope) for each API,
>> and define role bindings of the users based on the permissions they
>> have. Then, assign them to the API operations.
>>
>> *API A*
>> view-scopeA - role1, role2
>> edit-scopeA - role2
>>
>> /a GET view-scopeA
>> /a POST edit-scopeA
>>
>> *API B*
>> view-scopeB - role1, role2
>> edit-scopeB - role2
>>
>> /b GET view-scopeB
>> /b POST edit-scopeB
>>
>> The main limitation of the above way is that we need to create 4 scopes
>> separately with 4 unique scope keys duplicating the scope-role bindings.
>> Hence, for such cases, it is ideal to have the capability to define the
>> scope-role bindings globally and reuse them in the API operations. So the
>> API developers can restrict access for the API operations of the APIs
>> globally.
>>
>> So there will be only two scopes which needs to be created globally.
>> view-scope - role1, role2
>> edit-scope - role2
>>
>> *API A*
>> /a GET view-scope
>> /a POST edit-scope
>>
>> *API B*
>> /b GET view-scope
>> /b POST edit-scope
>>
>> In addition to the above, if there will be later requirement where there
>> is another set of users with a different set of permissions (role3) and
>> they need to be given permission to use (/b GET) operation of API B. If so,
>> with the above design where we do not support multiple scopes per resource,
>> we need to create another new scope with all role1, role2, and role3
>> bindings. Then assign it for (/b GET) instead of edit-scope. In that case,
>> the point of reusing global scopes across multiple APIs would not become
>> beneficial. Hence, by supporting multi

Re: [Architecture] [APIM] Support Global OAuth2 Scopes and Attaching Multiple Scopes per API Resource

[Dushani Wellappili]

Hi all,

According to the recent discussions we've had, we have modified the initial
DB design as follows.

   - Remove the FK constraint on SCOPE_ID, as it would be easy when
   decoupling API-M from IS components in the future.
   - Add a UUID for Global Scopes to support REST APIs

AM_GLOBAL_SCOPE
 SCOPE_ID INTEGER NOT NULL,
 TENANT_ID INTEGER DEFAULT -1,
 UUID VARCHAR (256)

In addition, the following points are highlighted which we need to
discuss further.

   - The management of scopes can be done in the Publisher Portal and it
   would make more sense if move it to the same UI view of APIs as scopes are
   straightly attached to APIs.
   - With the above design of global scopes, there will be no way to
   differentiate global and local scopes from the swagger. Hence, if the
   global scope - role bindings are updated after publishing the API, the role
   changes will not be reflected when validating API requests using Basic
   Auth. In such cases, we need to republish the APIs.
   - Currently, we do not support adding local scopes with the same name
   for different APIs. Hence, other than using local scopes to restrict the
   use of the same for other APIs, there would not be any difference between
   local and global scopes.
   - If we are removing local scope support, we need to migrate the
   existing local scopes of previous versions to global. In migration, we need
   to add the existing scope_ids and tenant_ids to the AM_GLOBAL_SCOPE table
   with new UUIDs.


Thanks

*Dushani Wellappili*
Senior Software Engineer - WSO2

Email : dusha...@wso2.com
Mobile : +94779367571
Web : https://wso2.com/




On Mon, Jan 20, 2020 at 11:19 AM Dushani Wellappili 
wrote:

> Hi all,
>
> This is to provide an example use-case of supporting global scopes when an
> application is using multiple APIs and it supports functionalities for
> users with different types of permissions. There are two sets of users
> where the one set will only have view-only permissions and another set will
> have both read and edit permissions.
>
> For example, assume an application is using both API A and B. API A has 2
> operations ( /a GET, /a POST) and similarly API B has 2 operations ( /b
> GET, /b POST). The users of set 1 only have read permission and set 2 have
> both read-write permissions. The permissions are given by assigning roles.
>
> set 1 user - role 1 (read-only role)
> set 2 users - role 2 (read-write role)
>
> The users of set 1 need to be provided access for both (/a GET) and (/b
> GET). The users of set 2 need to be provided access for all the 4
> operations (/a GET, /a POST, /b GET, /b POST) of API A and API B.
>
> With the current functionality of WSO2 API-M local scopes, this can be
> achieved by creating 2 local scopes (view-scope, edit-scope) for each API,
> and define role bindings of the users based on the permissions they
> have. Then, assign them to the API operations.
>
> *API A*
> view-scopeA - role1, role2
> edit-scopeA - role2
>
> /a GET view-scopeA
> /a POST edit-scopeA
>
> *API B*
> view-scopeB - role1, role2
> edit-scopeB - role2
>
> /b GET view-scopeB
> /b POST edit-scopeB
>
> The main limitation of the above way is that we need to create 4 scopes
> separately with 4 unique scope keys duplicating the scope-role bindings.
> Hence, for such cases, it is ideal to have the capability to define the
> scope-role bindings globally and reuse them in the API operations. So the
> API developers can restrict access for the API operations of the APIs
> globally.
>
> So there will be only two scopes which needs to be created globally.
> view-scope - role1, role2
> edit-scope - role2
>
> *API A*
> /a GET view-scope
> /a POST edit-scope
>
> *API B*
> /b GET view-scope
> /b POST edit-scope
>
> In addition to the above, if there will be later requirement where there
> is another set of users with a different set of permissions (role3) and
> they need to be given permission to use (/b GET) operation of API B. If so,
> with the above design where we do not support multiple scopes per resource,
> we need to create another new scope with all role1, role2, and role3
> bindings. Then assign it for (/b GET) instead of edit-scope. In that case,
> the point of reusing global scopes across multiple APIs would not become
> beneficial. Hence, by supporting multiple scopes per resource, we can keep
> the above design as it is and separately create a global/local scope with
> bindings for role3 and attach it to (/b GET) operation.
>
> new-scope - role3
>
> *API B*
> /b GET view-scope, new-scope
> /b POST edit-scope
>
>
>
> *Dushani Wellappili*
> Senior Software Engineer - WSO2
>
> Email : dusha...@wso2.com
> Mobile : +94779367571
> Web : https://wso2.com/
>
>
>
>
> On Thu, Jan 16, 2020 at 10:18 PM Dushani Wellappili 
> wrote:
>
>> The delete operation should be corrected as follows.
>>
>> #-
>>
>> # Delete the global scope
>>
>> #-

Re: [Architecture] [APIM] Support Global OAuth2 Scopes and Attaching Multiple Scopes per API Resource

[Dushani Wellappili]

Hi all,

This is to provide an example use-case of supporting global scopes when an
application is using multiple APIs and it supports functionalities for
users with different types of permissions. There are two sets of users
where the one set will only have view-only permissions and another set will
have both read and edit permissions.

For example, assume an application is using both API A and B. API A has 2
operations ( /a GET, /a POST) and similarly API B has 2 operations ( /b
GET, /b POST). The users of set 1 only have read permission and set 2 have
both read-write permissions. The permissions are given by assigning roles.

set 1 user - role 1 (read-only role)
set 2 users - role 2 (read-write role)

The users of set 1 need to be provided access for both (/a GET) and (/b
GET). The users of set 2 need to be provided access for all the 4
operations (/a GET, /a POST, /b GET, /b POST) of API A and API B.

With the current functionality of WSO2 API-M local scopes, this can be
achieved by creating 2 local scopes (view-scope, edit-scope) for each API,
and define role bindings of the users based on the permissions they
have. Then, assign them to the API operations.

*API A*
view-scopeA - role1, role2
edit-scopeA - role2

/a GET view-scopeA
/a POST edit-scopeA

*API B*
view-scopeB - role1, role2
edit-scopeB - role2

/b GET view-scopeB
/b POST edit-scopeB

The main limitation of the above way is that we need to create 4 scopes
separately with 4 unique scope keys duplicating the scope-role bindings.
Hence, for such cases, it is ideal to have the capability to define the
scope-role bindings globally and reuse them in the API operations. So the
API developers can restrict access for the API operations of the APIs
globally.

So there will be only two scopes which needs to be created globally.
view-scope - role1, role2
edit-scope - role2

*API A*
/a GET view-scope
/a POST edit-scope

*API B*
/b GET view-scope
/b POST edit-scope

In addition to the above, if there will be later requirement where there is
another set of users with a different set of permissions (role3) and they
need to be given permission to use (/b GET) operation of API B. If so, with
the above design where we do not support multiple scopes per resource, we
need to create another new scope with all role1, role2, and role3 bindings.
Then assign it for (/b GET) instead of edit-scope. In that case, the point
of reusing global scopes across multiple APIs would not become beneficial.
Hence, by supporting multiple scopes per resource, we can keep the above
design as it is and separately create a global/local scope with bindings
for role3 and attach it to (/b GET) operation.

new-scope - role3

*API B*
/b GET view-scope, new-scope
/b POST edit-scope



*Dushani Wellappili*
Senior Software Engineer - WSO2

Email : dusha...@wso2.com
Mobile : +94779367571
Web : https://wso2.com/




On Thu, Jan 16, 2020 at 10:18 PM Dushani Wellappili 
wrote:

> The delete operation should be corrected as follows.
>
> #-
>
> # Delete the global scope
>
> #-
>
> delete:
>
>   security:
>
> - OAuth2Security:
>
>   - apim:global_scope_manage
>
>   summary: Delete a global scope
>
>   description: |
>
> This operation can be used to delete an existing Global Scope
> proving the Id of the scope.
>
>   parameters:
>
> - $ref: '#/parameters/scopeId
>
>   responses:
>
> 200:
>
>   description: |
>
> OK.
>
> Resource successfully deleted.
>
> 404:
>
>   description: |
>
> Not Found.
>
> The resource to be deleted does not exist.
>
>   schema:
>
> $ref: '#/definitions/Error'
>
>
>
> *Dushani Wellappili*
> Senior Software Engineer - WSO2
>
> Email : dusha...@wso2.com
> Mobile : +94779367571
> Web : https://wso2.com/
>
>
>
>
> On Thu, Jan 16, 2020 at 3:33 PM Dushani Wellappili 
> wrote:
>
>> Hi all,
>>
>>- Global OAuth2 Scopes are useful when an organization/department (a
>>tenant) has a need to globally control the fined grained access control
>>permissions of all the published APIs, from a central place.
>>- It reduces the rework of creating the same scope with duplicate
>>access control permissions for each of the API. With this, such scope
>>creation would be a one time task. Global scopes will be created by
>>administrative users and the API developers can attach the available 
>> global
>>scopes for the API resources when designing the API.
>>- The support to add multiple OAuth scopes per resource is useful
>>when you need to group the access permissions to resources by scopes and
>>reuse them across different APIs.
>>
>> *DESIGN*
>>
>>- The global scope management view will be added to the Publisher UI
>>so that the API developers can easily check what are the available global

Re: [Architecture] [IAM] Supporting email verification when user’s email address is updated

[Malithi Edirisinghe]

On Sat, Jan 18, 2020 at 6:18 PM Johann Nallathamby  wrote:

> Hi Malithi, Hi Ajanthan,
>
> OK. So if we think like that, how do you propose we do 2FA for security
> question update? Are you implying that we initiate a SSO flow with higher
> requested assurance level, so that in IS a step-up authentication is
> performed and returned back to the service provider, to update his/her
> security questions?
>

Yes. And we can do this with conditional auth scripts.


>
> If this is possible with IS then +1 for that. But also I would like to
> have in the roadmap to do this purely through Rest APIs without ever
> leaving the service provider.
>

I think it's subjective. Maybe if it's some email or mobile based
confirmation it would be fine. But, for advanced options service provider
will have to manage user interactions if so. What would be the tendency to
implement such in SP level.


> Regards,
> Johann.
>
> On Thu, Jan 16, 2020 at 7:28 AM Malithi Edirisinghe 
> wrote:
>
>> Hi Johann,
>>
>> On Wed, Jan 8, 2020 at 4:49 AM Ajanthan Balachandran 
>> wrote:
>>
>>> Hi Johann,
>>>
>>> I think here we are talking about two different things. Feel free to
>>> correct me if I am wrong.
>>>
>>> In the first case, we are trying to assert the value of the claims
>>> provided by the user. In the case of phone number and email claims sending
>>> verification code does make sense but to assert the first name or last name
>>> sending verification code to email or phone doesn't give enough
>>> assurance(usually photo ID proof is needed to verify names).
>>>
>>> What you are talking about is getting enough assurance level for the
>>> authenticated user by prompting 2FA to be able to update security
>>> questions. This should be handled by auth system not the claim verification
>>> system.
>>>
>>
>> I'm under the same understanding with Ajanthan.
>> It should be a 2FA flow.
>>
>>
>>>
>>> Thanks,
>>> Ajanthan.
>>>
>>>
>> Thanks,
>> Malithi
>> --
>> *Malithi Edirisinghe* | Technical Lead | WSO2 Inc.
>> (m) +94 718176807 | (w) +94 11 214 5345 | (e) malit...@wso2.com
>> GET INTEGRATION AGILE
>> Integration Agility for Digitally Driven Business
>>
>
>
> --
> *Johann Dilantha Nallathamby* | Associate Director/Solutions Architect |
> WSO2 Inc.
> (m) +94 (77) 7776950 | (w) +94 (11) 2145345 | (e) joh...@wso2.com
> [image: Signature.jpg]
>


-- 
*Malithi Edirisinghe* | Technical Lead | WSO2 Inc.
(m) +94 718176807 | (w) +94 11 214 5345 | (e) malit...@wso2.com
GET INTEGRATION AGILE
Integration Agility for Digitally Driven Business
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 API Manager 3.1.0-Alpha Released!

[Krishan Wijesena]

The WSO2 API Manager team is pleased to announce the release of version
3.1.0-Alpha of API Manager.Downloads

wso2am-3.1.0-alpha.zip


wso2am-analytics-3.1.0-alpha.zip

How to Run

   1. Extract the downloaded zip
   2. Go to the bin directory in the extracted folder
   3. Run the wso2server.sh or wso2server.bat as appropriate
   4. Launch a web browser and navigate to https://localhost:9443/publisher to
   access the API publisher
   5. Navigate to https://localhost:9443/devportal to access the API
   Developer Portal
   6. Navigate to https://localhost:9443/admin to access Admin Portal
   7. Use "admin", "admin" as the username and password to login as an admin

What's new in WSO2 API Manager 3.1.0-Alpha

   - GitHub (product-apim
   

   , analytics-apim
   )

Known Issues

All the open issues pertaining to WSO2 API Manager are reported at the
following location:

   - GitHub (product-apim
   

   , analytics-apim )

How You Can Contribute

*Mailing Lists*
Join our mailing list and correspond with the developers directly.

Developer List: d...@wso2.org | Subscribe | Mail Archive

User List: u...@wso2.org | Subscribe | Mail Archive

*Reporting Issues*

We encourage you to report issues, improvements and feature requests
regarding WSO2 API Manager through WSO2 API Manager GIT Issues
.

And please be advised that, security issues must be reported to
secur...@wso2.com, not as GitHub issues, in order to reach proper audience.
We strongly advise following the WSO2 Security Vulnerability Reporting
Guidelines

when
reporting the security issues.


*-- The WSO2 API Manager Team --*

-- 

*Krishan Wijesena*
Senior Software Engineer | WSO2

Email : krish...@wso2.com
Mobile : +94776219923
WSO2 Inc : http://wso2.com
[image: http://wso2.com/signature] 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture