[Architecture] WSO2 Identity Server 5.10.0-alpha3 Released!

[Tharindu Bandara]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.10.0 Alpha3!

Download

You can download WSO2 Identity Server 5.10.0 Alpha3 from here

.
How
to run

   1. Extract the downloaded zip file.
   2. Go to the *bin* directory in the extracted folder.
   3. Run the *wso2server.sh* file if you are on a Linux/Mac OS or run the
   *wso2server.bat* file if you are on a Windows OS.
   4. Optionally, if you need to start the OSGi console with the server,
   use the *-DosgiConsole* property when starting the server.

What's
new in WSO2 Identity Server 5.10.0 Alpha3

A list of all the new features and bug fixes shipped with this release can
be found here .
Known
Issues

All the open issues pertaining to WSO2 Identity Server are reported at the
following location:

   - IS Runtime 

Contribute
to WSO2 Identity Server
Mailing
Lists

Join our mailing lists and correspond with the developers directly. We also
encourage you to take part in discussions related to the product in the
architecture mailing list. If you have any questions regarding the product
you can use our StackOverflow forum to raise them as well.

   - Developer List: d...@wso2.org
   - Architecture List: architecture@wso2.org
   - User Forum: StackOverflow
   

Slack
Channels

Join us via our wso2is.slack.com

for
even better communication. You can talk to our developers directly
regarding any issues, concerns about the product. We encourage you to start
discussions or join any ongoing discussions with the team, via our slack
channels.

   - Discussions about developments: Dev Channel
   
   - New releases: Release Announcement Channel
   

Reporting
Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server GIT
Issues .

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

when
reporting the security issues.*

For more information about WSO2 Identity Server, please see
 https://wso2.com/identity-and-access-management
 or visit the WSO2 Oxygen
Tank  developer portal for additional resources.

~ The WSO2 Identity and Access Management Team ~
-- 
*Tharindu Bandara*
Senior Software Engineer | WSO2

Email : tharin...@wso2.com
Mobile : +94 714221776
web : http://wso2.com


https://wso2.com/signature
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Sathya Bandara]

Hi Malithi,

On Tue, Feb 4, 2020 at 12:38 AM Malithi Edirisinghe 
wrote:

> Hi Sathya,
>
> On Mon, Feb 3, 2020 at 9:20 PM Sathya Bandara  wrote:
>
>> Hi Dewni,
>>
>> In SCIM, it allows to define email addresses as a primitive strings as
>> well. In the current architecture, we are using the
>> http://wso2.org/claims/emailaddress to store the emails as a comma
>> separated string. For example, the following request is a valid case in
>> SCIM.
>>
>> curl -v -k --user admin:admin --data
>> '{"schemas":[],"name":{"familyName":"sathya","givenName":"sathya"},"userName":"sathya","password":"sathya","emails":["
>> sat...@wso2.com","sat...@test.com"]}' --header
>> "Content-Type:application/json" https://localhost:9443/scim2/Users
>>
>
> It seems to me that we are doing something odd, than what SCIM spec
> defines on multi valued attributes. Ideally, there should be a type
> incorporated if it's a multi valued one.
>
The spec defines that elements of a Multi-Valued Attributes can be either
primitive values, or objects with a set of sub-attributes and values as per
[1]. Therefore IMO, we should support both options. WDYT?

[1] https://tools.ietf.org/html/rfc7643#section-2.4

>
>
> Proceeding forward, I think we may have to provide support to verify
> multiple emails in the http://wso2.org/claims/emailaddress claim if
> exists, or introduce a new claim e.g. http://wso2.org/claims/emails to
> store the primitive values.
>

I don't think we should recommend that. Rather we should recommend to use
separate claims indicating type, and map that to a single multi valued
attribute in SCIM. And that's where we should be supporting verifications.
Having multiple values in one claim and allowing to update each with
verifications will complicate the case and we will have to
incorporate another structure, than followed to maintain the mapping among
existing and pending verification, which needs to be processed differently
case by case, making it hard to be managed


>
> Thanks,
> Sathya
>
> On Wed, Jan 29, 2020 at 4:50 PM Dewni Weeraman  wrote:
>
>> Hi All,
>>
>> The "emailaddress.verificationPending" (
>> http://wso2.org/identity/claims/emailaddress.verificationPending) claim
>> suggests a boolean value instead of the actual email value. Therefore we
>> will modify the claim name as "emailaddress.pendingValue" (
>> http://wso2.org/identity/claims/emailaddress.pendingValue) to avoid
>> any confusion.
>>
>> As discussed previously, we will be providing the verification on update
>> functionality for the "emailaddress" (http://wso2.org/claims/emailaddress)
>> claim for now. However, we have planned to extend this functionality for
>> other claims such as "emails.work" (http://wso2.org/claims/emails.work)
>> and "emails.home" (http://wso2.org/claims/emails.home) in the future.
>> Therefore it is important to have a proper format when representing these
>> verification pending claims in the SCIM response. The ideal solution is to
>> have a "pendingValue" for each of these claims.
>>
>> Please find the sample request and response.
>>
>> Request:
>>
>> *curl -v -k --user admin:admin -X PATCH -d
>> '{"schemas":["urn:ietf:params:scim:api:messages:2.0:PatchOp"],"Operations":[
>> {"op":"replace","value":{"emails":[{"primary":true,"value":"de...@xyz.com.com
>> "}]}}]}' --header "Content-Type:application/json"
>> https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109
>> *
>>
>>
>> Response:
>>
>> *{"emails":["de...@abc.com
>> "],"meta":{"created":"2020-01-28T05:13:13.992017Z","location":"https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109
>> ","lastModified":"2020-01-28T06:04:36.421652Z","resourceType":"User"},"nickName":"dewni1","schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default","value":"Internal/everyone"}],"name":{"givenName":"dewni","familyName":"jackson"},"id":"705cc75d-2640-4c3d-9848-e055a9eb6109","userName":"dewnitest","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User":{"emails":[{"pendingValue":"de...@xyz.com
>> "}]}}*
>>
>> When we extend the feature to support verification of other claims such
>> as "emails.work" in the future, the SCIM 2.0 response should be as below.
>>
>> Response:
>>
>> *{"emails":["de...@abc.com ", 
>> **{"type":"work","value":"de...@work.com
>> "},{"type":"home","value":"de...@home.com
>> "}**],"meta":{"created":"2020-01-28T05:13:13.992017Z","location":"https://localhost:9443/scim2/Users/705cc75d-2640-4c3d-9848-e055a9eb6109
>> ","lastModified":"2020-01-28T06:04:36.421652Z","resourceType":"User"},"nickName":"dewni1","schemas":["urn:ietf:params:scim:schemas:core:2.0:User","urn:ietf:params:scim:schemas:extension:enterprise:2.0:User"],"roles":[{"type":"default

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

[Ishara Cooray]

Hi Dushani,

If a global scope is modified or deleted it will affect all the APIs that
it is being used.
How do we handle this?
There should be a way to identify the APIs that the scope is
associated with.
And when deleting we need to make sure that none of the APIs using the
scope. When modifying we need to at least warn about the usages of the
scope.
Also, it will introduce complexities when it comes to tenants.

IMO we should not allow modifying/deleting global scopes because we can
easily create a new scope to match the requirements.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Mon, Jan 27, 2020 at 12:04 PM Dushani Wellappili 
wrote:

> Hi Rushmin,
>
>
> On Fri, Jan 24, 2020 at 5:37 PM Rushmin Fernando  wrote:
>
>>
>>
>> On Mon, Jan 20, 2020 at 12:29 PM Amila De Silva  wrote:
>>
>>> 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.
>>>
>>>
>> I believe that the UX of an API publisher gets affected due to the
>> following reasons if we allow only global scopes and not facilitate them
>> properly.
>>
>> - Two scopes might have the same name but might have two different
>> semantics in the context of two APIs.
>>
>
> Even with the current behavior (with local scopes), we do not provide the
> capability to have the same name for scopes of two different APIs.
> Irrespective of whether its a local or global scope, we will not allow
> having duplicate scope keys/names.
>
>
>> - There might be scopes which are semantically same but have different
>> names.
>>
> This is a case where we cannot control. IMO, it is a design choice of the
> privileged user/admin to create different scopes with same role bindings
> and use them across multiple APIs.
>
>>
>> So this might create confusion when choosing the scopes for an API unless
>> this is well-governed.
>>
>>
>>
>>> 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 remov

Re: [Architecture] PDF Report Generation for APIM Analytics

[Ishara Cooray]

In addition to the above, I think it will be useful if we could provide the
report in CSV format as well.

Thanks & Regards,
Ishara Cooray
Associate Technical Lead
Mobile : +9477 262 9512
WSO2, Inc. | http://wso2.com/
Lean . Enterprise . Middleware


On Thu, Jan 9, 2020 at 10:18 AM Kavishka Fernando  wrote:

> Regarding the report generation, Can't we render HTML pages as reports and
>> give users a print button to print or download it as PDF? In this way, I
>> think we will have more flexibility in styling and arranging the report
>> data. Basically providing a printable version of  the widget (Graph/Table/
>> pie chart etc,)
>
>
> +1 for this. Users can get more information about analytics and customize
> the report accordingly.
>
> On Thu, Jan 9, 2020 at 7:26 AM Fazlan Nazeem  wrote:
>
>> Hi Harsha,
>>
>> On Mon, Jan 6, 2020 at 9:52 PM Harsha Kumara  wrote:
>>
>>> Can we select range when generating the report? Also we need to evaluate
>>> what are the common requirements and provide the capability to generate the
>>> reports based on it.
>>>
>> The initial version may only have the capability to generate reports for
>> a particular month of an year. We will implement reports for a range of
>> time in the upcoming versions.
>>
>>>
>>> On Mon, Jan 6, 2020 at 5:47 PM Fazlan Nazeem  wrote:
>>>
 Hi all,

 We have been constantly getting requests from customers to have a
 proper PDF reporting mechanism where users can export analytics data in PDF
 format. Therefore we have implemented a prototype of this feature for the
 upcoming 3.1 release.

 The current prototype is implemented by exposing an MSF4J rest service
 which will generate a hit count report for a particular month, year
 combination. The month, year combination has to be passed as query params
 to the API. Attached herewith is a PDF report generated by this service. We
 are thinking of adding two more types of reports if time permits.
 Altogether this makes 3 types of reports which can be downloaded.

 1) Request Summary
 2) Throttle Summary
 3) Fault summary

 The plan is to secure the service with tenant admin credentials. This
 means not all users who visit the analytics dashboard will be able to
 download the PDF report unless he/she is an admin. We are thinking of
 exposing a new dashboard with a single widget that takes the inputs (year,
 month) and downloads this report. The dashboard will be secured with admin
 role, resulting in only admin users being able to view this dashboard. The
 rationale behind this decision is not to expose analytics data of publisher
 access-controlled APIs to normal API publishers.

 Please provide your suggestions on any improvements or changes which
 can add value to this feature.

 --
 Thanks & Regards,

 *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
 Mobile : +94772338839 | fazl...@wso2.com



>>>
>>> --
>>>
>>> *Harsha Kumara*
>>>
>>> Technical Lead, WSO2 Inc.
>>> Mobile: +94775505618
>>> Email: hars...@wso2.coim
>>> Blog: harshcreationz.blogspot.com
>>>
>>> GET INTEGRATION AGILE
>>> Integration Agility for Digitally Driven Business
>>>
>> --
>> Thanks & Regards,
>>
>> *Fazlan Nazeem | *Associate Technical Lead | WSO2 Inc
>> Mobile : +94772338839 | fazl...@wso2.com
>>
>>
>>
>
> --
> *Kavishka Fernando*
> *Software Engineer | WSO2*
> Email: kavis...@wso2.com
> Mobile:  +94773838069
> Web: http://wso2.com
> Blog: https://medium.com/@kavishkafernando
>
> 
>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Dushani Wellappili]

Hi Ishara,

We will not allow deleting global scopes if they are attached to any
resource. Btw, Global scopes cannot be used across tenants, global scopes
can be defined locally to a tenant. When a global scope is updated (role
binding updates), we will provide a warning about the need to republish the
APIs. Because role binding updates will not immediately reflect in the
swagger unless we republish. Basic auth will not work properly in such
cases.



*Dushani Wellappili*
Senior Software Engineer - WSO2

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




On Wed, Feb 5, 2020 at 5:31 AM Ishara Cooray  wrote:

> Hi Dushani,
>
> If a global scope is modified or deleted it will affect all the APIs that
> it is being used.
> How do we handle this?
> There should be a way to identify the APIs that the scope is
> associated with.
> And when deleting we need to make sure that none of the APIs using the
> scope. When modifying we need to at least warn about the usages of the
> scope.
> Also, it will introduce complexities when it comes to tenants.
>
> IMO we should not allow modifying/deleting global scopes because we can
> easily create a new scope to match the requirements.
>
> Thanks & Regards,
> Ishara Cooray
> Associate Technical Lead
> Mobile : +9477 262 9512
> WSO2, Inc. | http://wso2.com/
> Lean . Enterprise . Middleware
>
>
> On Mon, Jan 27, 2020 at 12:04 PM Dushani Wellappili 
> wrote:
>
>> Hi Rushmin,
>>
>>
>> On Fri, Jan 24, 2020 at 5:37 PM Rushmin Fernando 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 20, 2020 at 12:29 PM Amila De Silva  wrote:
>>>
 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.


>>> I believe that the UX of an API publisher gets affected due to the
>>> following reasons if we allow only global scopes and not facilitate them
>>> properly.
>>>
>>> - Two scopes might have the same name but might have two different
>>> semantics in the context of two APIs.
>>>
>>
>> Even with the current behavior (with local scopes), we do not provide the
>> capability to have the same name for scopes of two different APIs.
>> Irrespective of whether its a local or global scope, we will not allow
>> having duplicate scope keys/names.
>>
>>
>>> - There might be scopes which are semantically same but have different
>>> names.
>>>
>> This is a case where we cannot control. IMO, it is a design choice of the
>> privileged user/admin to create different scopes with same role bindings
>> and use them across multiple APIs.
>>
>>>
>>> So this might create confusion when choosing the scopes for an API
>>> unless this is well-governed.
>>>
>>>
>>>
 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 mo

[Architecture] [IAM] InCommon Federation compliance for WSO2 Identity Server

[Sithara De Silva]

Hi All,

This mail is regarding the project InCommon Federation compliance for WSO2
Identity Server. The main objective of the 1st phase of this project was to
gather requirements of InCommon Federation which are needed to comply with
their participating Service Provider and Identity Provider applications.
With that, we were able to identify the gaps in WSO2 IS to support the
InCommon Federation and the approaches to cater to the gaps identified.

Refer [1],[2],[3] for more details.

During federation, entities should be identified by each other for
communication. So they need to exchange their metadata in a trusted manner.
Each organization should submit metadata of the SPs’ and IdPs’ to the
InCommon during the registration process uniquely. The metadata submitted
by organizations is aggregated into aggregates where the entities can
download it through permanent HTTP locations.



Metadata refreshment is updating the already configured data about SPs and
IdPs in the WSO2 Identity Server. InCommon specifically mentions the
following flow of activities for the metadata refreshment




   1.

   Choose one of three metadata aggregates (Preview, Main, & Fallback)
   2.

   Obtain an authentic copy of the Metadata Signing Certificate
   3.

   Using the Metadata Client Software (WSO2 IS)
   1.

  Refresh metadata at least daily (but more often if possible, minimum
  hourly)
  2.

  Validate the expiration date on downloaded metadata
  3.

  Verify the XML signature on downloaded metadata
  4.

   Adjust outbound firewall rules (if necessary)


There were different requirements identified and WSO2 Identity Server needs
to do some modifications to support InCommon federation.

InCommon Federation requirements can be mainly categorized into three parts.

   1.

   Compatibility of SAML V2.0
   2.

   Federation Metadata Refreshment
   3.

   Support eduPerson Attributes

SAML V2.0 compatibility

   1.

   Regarding the SAML v2.0 requirements, the following metadata elements
   are not included in WSO2 IS
   1.

  Scope in IdP metadata
  2.

  User Interface Information
  3.

  Contact information
  2.

   There is an error-handling URL already in the IS, but it doesn’t resolve
   the required purpose of InCommon Federation.
   3.

   There are not  element used in metadata but InCommon
   Federation metadata contains  elements for “RegistrationInfo”,
   and “Organization” tags

Federation Metadata Refreshment

   1.

   No any method to automatically refresh metadata in WSO2 IS
   2.

   There is an option for SP file configuration in IS, but it also requires
   to have one file for one SP
   3.

   No way to any file configuration for IdP
   4.

   No HTTP Conditional GET supports to use in the hourly refreshment of
   metadata in IS
   5.

   No option to search configured SPs and IdP in IS management console
   6.

   No technical implementation to read a large XML file and configure SPs
   and IdPs

Support eduPerson Attributes

   1.

   No eduPerson claim dialect is available in IS
   2. No attribute such as FriendlyName to include in the SAML response.


Approaches to Cater to the Gaps

   1.

   As eduPerson attributes are not included in any existing claim dialect,
   a new claim dialect should be implemented. Using that, claims in WSO2 local
   dialect can be mapped into relevant eduPerson claims.
   2.

   Use the description section to map FriendlyName of the attribute since
   it requires in the SAML response. This may be changed if there is a better
   way
   3.

   Create independent CLI tool to handle the entire metadata refreshment
   process
   4.

   That will synchronously configure SPs and IdPs into the server. There
   will not be any overheads in IS, other tasks are also safe to proceed
   5.

   Allow HTTP Conditional GET support in tool. Thus, the hourly refreshment
   process of metadata can be done
   6.

   Add new feature to IS for searching already configured SPs and IdPs
   7.

   The tool will be able to read the desired metadata aggregate and give
   those SPs and IdPs metadata to relevant APIs to configure in IS
   8.

   When the configuration is happening, the system will display the current
   process of the configuration either configuring, success, or failed
   9.

   There will be another feature to track failed SPs and IdPs in the
   configuration process.


The architecture Diagram for the Metadata management and refreshment
process in WSO2 IS.


[1]. [Dev] [IS] InCommon Federation Compliance for WSO2IS - UI Component

[2]. [IAM] Configure Requested Claims based on the Service Provider Claim
Dialect

[3]. [Dev][IAM] InCommon Federation Compliance for WSO2IS - eduPerson Claim
Dialect

Kind regards,
Sithara Nishadini
-- 

*Sithara Nishadini*| Intern | WSO2 Inc.

(m) 0719801636 |(e) sith...@wso2.com

[image: https://wso2.com/signature] 
___
Architecture