[Dev] WSO2 Identity Server 5.11.0 M11 Released!

[Inthirakumaaran Tharmakulasingham]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.11.0 M11!

Download

You can download WSO2 Identity Server 5.11.0 M11 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

*Admin Portal*

   - User-stores option where we can add new user stores and manage them.



   - Server configurations option where we can manage user registration and
   account recovery configurations.



*Identity Core*

   - Tenant-qualify SAML and OIDC metadata endpoints.


*Other fixes & features*

A list of all the new features and bug fixes shipped with this release can
be found in the following locations:


   - IS Runtime 
   - IAM Portals
   

Known
Issues

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

   - IS Runtime 
   - IAM Portals
   

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: dev@wso2.org
   - Architecture List: architect...@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 ~

-- 
*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [Architecture] Maintaining IS-Archetypes

[Inthirakumaaran Tharmakulasingham]

Hi Darshana,

Currently we don't have an archetype for that.

Regards,
Kumaaran


On Tue, 24 Dec 2019, 20:17 Darshana Gunawardana,  wrote:

> Do we have an archetype for PostAuthenticationHandlers?
>
> On Wed, Oct 9, 2019 at 3:37 PM Inthirakumaaran Tharmakulasingham <
> inthirakumaa...@wso2.com> wrote:
>
>> Hi all,
>>
>> We had an offline discussion with  @Darshana Gunawardana
>>  @Omindu Rathnaweera  @Jayanga
>> Kaushalya  @Yasara Yasawardhana  @Janak
>> Amarasena  @Pulasthi Mahawithana .
>> There we decided the following
>>
>>- Regarding Maintenance:
>>   - Have a separate repo for IS-archetypes. We planned to go with
>>   the name *archetypes-is* for the repo
>>   - Go with four-digit release
>>  - major -- product release
>>  - minor -- addition of a new archetype
>>  - patch -- improve
>>  - 4th digit -- track archetype life
>>   - For each product version, a branch will be created and
>>   compatible archetypes for that versions will be maintained there
>>- Archetype Structure:
>>   - The structure in the above mail is acceptable.
>>   - Within comments, have the sample codes for the methods.
>>   - Have the data holder pattern. But according to the situation, we
>>   can drop this.
>>   - The component name will be taken as input and appended as a
>>   prefix.
>>  - eg for user operation event listener --
>>  {listener-name}UserOperationEventListener.java
>>
>> Please share your thoughts on this
>>
>> Thanks and Regards
>> kumaaran
>>
>> On Wed, Sep 11, 2019 at 9:20 PM Inthirakumaaran Tharmakulasingham <
>> inthirakumaa...@wso2.com> wrote:
>>
>>> Hi all,
>>>
>>> We have updated the dependency of user-event-listener-archetype[1] and
>>> now it can work on IS 5.8.0. While deciding on where to put these
>>> archetypes, let's try to finalize the format of archetypes by analyzing the
>>> user-event-listener-archetype.
>>>
>>> Following is the structure of this archetype.
>>>
>>> carbon-user-operation-eventListener-archetype
>>>> └── src
>>>> ├── main
>>>> │   └── resources
>>>> │   ├── META-INF
>>>> │   │   └── maven
>>>> │   │   └── archetype-metadata.xml
>>>> │   └── archetype-resources
>>>> │   ├── pom.xml
>>>> │   └── src
>>>> │   └── main
>>>> │   └── java
>>>> │   ├──
>>>> __listener-name-prefix__UserOperationEventListener.java
>>>> │   └── internal
>>>> │   └──
>>>> __listener-name-prefix__UserOperationEventListenerServiceComponent.java
>>>> └── test
>>>> └── resources
>>>> └── projects
>>>> └── basic
>>>> ├── archetype.properties
>>>> └── goal.txt
>>>
>>>
>>> We have to think of the components we can add to this archetypes. Eg we
>>> can add data-holder class which could help the user to customize these
>>> archetypes.
>>>
>>> Then we have to consider the naming as well, eg what group id should be
>>> given for which archetype or how the classes in the archetype should be
>>> named whether to add a suffix or have a fixed name
>>>
>>> Please share your thoughts on this
>>>
>>> [1]https://github.com/wso2-extensions/archetypes/pull/26
>>>
>>> On Wed, Aug 7, 2019 at 7:25 PM Kanapriya Kuleswararajan <
>>> kanapr...@wso2.com> wrote:
>>>
>>>> Hi Shankar,
>>>>
>>>> On Wed, Aug 7, 2019 at 4:56 PM Selvaratnam Uthaiyashankar <
>>>> shan...@wso2.com> wrote:
>>>>
>>>>>
>>>>>
>>>>> On Wed, Aug 7, 2019 at 2:23 PM Tharindu Bandara 
>>>>> wrote:
>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> Find the best approach to maintain the archetypes (in a single repo
>>>>>>> or inside the feature repo).
>>>>>>
>>>>>>
>>>>> I didn't understand what do we meant by feature repo here. Still it is
>>>>> going to be single repo right?
>>>>>

Re: [Dev] [Architecture] Maintaining IS-Archetypes

[Inthirakumaaran Tharmakulasingham]

Hi all,

We had an offline discussion with  @Darshana Gunawardana 
 @Omindu Rathnaweera  @Jayanga Kaushalya
 @Yasara Yasawardhana  @Janak Amarasena
 @Pulasthi Mahawithana . There we
decided the following

   - Regarding Maintenance:
  - Have a separate repo for IS-archetypes. We planned to go with the
  name *archetypes-is* for the repo
  - Go with four-digit release
 - major -- product release
 - minor -- addition of a new archetype
 - patch -- improve
 - 4th digit -- track archetype life
  - For each product version, a branch will be created and compatible
  archetypes for that versions will be maintained there
   - Archetype Structure:
  - The structure in the above mail is acceptable.
  - Within comments, have the sample codes for the methods.
  - Have the data holder pattern. But according to the situation, we
  can drop this.
  - The component name will be taken as input and appended as a prefix.
 - eg for user operation event listener --
 {listener-name}UserOperationEventListener.java

Please share your thoughts on this

Thanks and Regards
kumaaran

On Wed, Sep 11, 2019 at 9:20 PM Inthirakumaaran Tharmakulasingham <
inthirakumaa...@wso2.com> wrote:

> Hi all,
>
> We have updated the dependency of user-event-listener-archetype[1] and now
> it can work on IS 5.8.0. While deciding on where to put these archetypes,
> let's try to finalize the format of archetypes by analyzing the
> user-event-listener-archetype.
>
> Following is the structure of this archetype.
>
> carbon-user-operation-eventListener-archetype
>> └── src
>> ├── main
>> │   └── resources
>> │   ├── META-INF
>> │   │   └── maven
>> │   │   └── archetype-metadata.xml
>> │   └── archetype-resources
>> │   ├── pom.xml
>> │   └── src
>> │   └── main
>> │   └── java
>> │   ├──
>> __listener-name-prefix__UserOperationEventListener.java
>> │   └── internal
>> │   └──
>> __listener-name-prefix__UserOperationEventListenerServiceComponent.java
>> └── test
>> └── resources
>> └── projects
>> └── basic
>> ├── archetype.properties
>> └── goal.txt
>
>
> We have to think of the components we can add to this archetypes. Eg we
> can add data-holder class which could help the user to customize these
> archetypes.
>
> Then we have to consider the naming as well, eg what group id should be
> given for which archetype or how the classes in the archetype should be
> named whether to add a suffix or have a fixed name
>
> Please share your thoughts on this
>
> [1]https://github.com/wso2-extensions/archetypes/pull/26
>
> On Wed, Aug 7, 2019 at 7:25 PM Kanapriya Kuleswararajan <
> kanapr...@wso2.com> wrote:
>
>> Hi Shankar,
>>
>> On Wed, Aug 7, 2019 at 4:56 PM Selvaratnam Uthaiyashankar <
>> shan...@wso2.com> wrote:
>>
>>>
>>>
>>> On Wed, Aug 7, 2019 at 2:23 PM Tharindu Bandara 
>>> wrote:
>>>
>>>> Hi all,
>>>>
>>>> Find the best approach to maintain the archetypes (in a single repo or
>>>>> inside the feature repo).
>>>>
>>>>
>>> I didn't understand what do we meant by feature repo here. Still it is
>>> going to be single repo right?
>>>
>>
>> The feature repo means, we thought to maintain the archetype in the same
>> repository where the feature is in. In that way, if we upgrade the product
>> or any feature component with the latest dependencies, we can update the
>> archetypes and can maintain the releases for archetypes as well (we may
>> need to maintain the old archetype version as there can be users who still
>> use the old product versions with lower dependency versions).
>>
>>>
>>> When we created the extensions, we make a conscious decision to have a
>>> separate repo for each extension. Each extension has its own release cycle.
>>> archetypes are also considered extensions. The version of the archetypes
>>> doesn't need to have a matching product version.
>>>
>>> Any difficulty we are facing by keeping them in separate repositories?
>>>
>>
>> I don't think any other difficulties in having each archetype in a
>> separate repo except the maintenance. Because, we have a couple of
>> archetypes in repo [1], but it's not in a stable state to use in latest
>> pro

Re: [Dev] [VOTE] Release WSO2 Identity Server 5.9.0 RC2

[Inthirakumaaran Tharmakulasingham]

Hi all,

I have tested the following scenarios

   - Authorization Code Grant
   - Client Credentials Grant
   - Implicit Grant
   - Password Grant
   - OIDC Request Path Authenticator
   - OIDC Implicit Redirect
   - OIDC Password Grant
   - SAML SSO with Redirect Binding
   - SAML SSO with Post Binding
   - Role-based adaptive authentication
   - Userstore based adaptive authentication

No blocker issues found

[+] Stable - go ahead and release

On Thu, Oct 3, 2019 at 7:10 PM Isuranga Perera  wrote:

> :All
>
> I have tested the following scenarios and no blocking issues found:
>
>- Outbound provisioning with SCIM and Salesforce
>
>
>- Federated authentication using Facebook
>
> [+] Stable - go ahead and release
>
> Thanks
> Isuranga
>
> On Thu, Oct 3, 2019 at 6:16 PM Piraveena Paralogarajah 
> wrote:
>
>> Hi all.
>>
>> I have tested the following scenarios:
>>
>>
>>
>>- Scope Management REST API
>>- XACML based scope validation for token issuing phase in the
>>following OAuth grant types
>>
>>
>>- Authorization code flow
>>   - password grant
>>   - client_credentials
>>   - Implicit flow
>>- XACML based authorization
>>
>> No blocker issues found
>> [+] Stable - go ahead and release
>>
>> Thanks,
>> Piraveena
>>
>> *Piraveena Paralogarajah*
>> Software Engineer | WSO2 Inc.
>> *(m)* +94776099594 | *(e)* pirave...@wso2.com
>>
>>
>>
>> On Thu, Oct 3, 2019 at 3:45 PM Ashen Weerathunga  wrote:
>>
>>> Hi All,
>>>
>>> I have tested the following scenarios and no blocking issues found.
>>>
>>>- SSO with SAML
>>>- Federated authentication with Google
>>>- Federated authentication with Facebook
>>>- SSO with multi-option and multi-step authentication
>>>- Role-based Adaptive authentication
>>>
>>> [+] Stable - go ahead and release
>>>
>>> Thanks,
>>> Ashen
>>>
>>>
>>> On Thu, Oct 3, 2019 at 2:34 PM Shanika Wickramasinghe 
>>> wrote:
>>>
 Hi All,

 I have tested the following features and no issues found

 Ubuntu 16.04 | MSSQL | Embedded Ldap Primary User Store | Super Tenant


-

Manage roles with SCIM 2.0 Create Group, Delete Group, Filter
Groups, Search Groups, Update Group - PATCH, Update Group - PUT
-

Manage users with SCIM 2.0 Create User Delete User by ID Filter
Users Search Users Update User - PATCH Update User - PUT
-

Recover Username with dashboard
-

Recover Password with dashboard


 Ubuntu 16.04 |  MSSQL | SecondaryUser Store | Super Tenant


-

SP pagination with UI
-

SP pagination with Admin Services
-

Account Lock
-

Recaptcha with Single Sign On


 Ubuntu 16.04 | H2/MSSQL | Embedded Ldap Primary User Store | Super
 Tenant


-

Manage Workflows


 Ubuntu 16.04 | H2 | Embedded Ldap Primary User Store | Super Tenant


-

Manage Workflows with QSG sample
-

User self-registration via REST APIs
-

User self-registration via user portal
-

User manage his own user account, Update user profile
-

OAuth 1.0 SP Creation/ Update


 +1 Go ahead and release.


 Thanks,

 Shanika

 On Thu, Oct 3, 2019 at 9:16 AM Achini Jayasena 
 wrote:

> Hi All,
>
> Tested and verified with performance test and long running test. Test
> result match with the expectations.
>
> *Performance test*
>
> Summary*:  *Performance has been improved comparing to the product
> version 5.8
>
> Deployment
>
>- OS: Ubuntu
>- DB: Mysql
>- Heap: 4G/2G
>- CPU cores: 4
>- Concurrent users: 50, 100, 150, 300, 500
>
> Scenarios:
>
>- Authenticate_Super_Tenant_User
>- OAuth_AuthCode_Redirect_WithConsent
>- OAuth_Client_Credentials_Grant
>- OAuth_Implicit_Redirect_WithConsent
>- OAuth_Password_Grant
>- OIDC_AuthCode_Redirect_WithConsent
>- OIDC_AuthCode_Request_Path_Authenticator_WithConsent
>- OIDC_Implicit_Redirect_WithConsent
>- OIDC_Password_Grant
>- SAML2_SSO_Redirect_Binding
>- Challenge questions by super tenant users
>- Refresh token refresh grant - Renewal false
>
> *Long running test*
>
> Summery*: *No issue reported.
>
> Deployment :
>
>- IS node
>- Instance type: c5.xlarge
>   - vCPU:4
>   - RAM: 8GB
>   - Heap: 2G allocated for IS
>
>
>- RDS as the MySQL DB
>- Mysql engine version : 5.7.22
>   - vCPU: 4
>   - Instance class : db.m4.xlarge
>   - RAM: 16 GB
>   - Storage: 100 GiB
>- Executing test scenarios:
>- 

Re: [Dev] [Architecture] Maintaining IS-Archetypes

[Inthirakumaaran Tharmakulasingham]

  the same repo? In this way, there can be chances that some archetypes 
>>>> get
>>>>released unnecessary (ie, without any changes).
>>>>- Or else we can keep the archetypes inside the feature repo itself?
>>>>
>>>> Appreciate your valuable suggestions on the above?
>>>>
>>>> Further, In this effort, we (myself and @Inthi) are planning the
>>>> following as the initial step:
>>>>
>>>>- Refactor the existing archetypes and Making that to work with IS
>>>>5.8.0 for now.
>>>>- Find the best approach to maintain the archetypes (in a single
>>>>repo or inside the feature repo).
>>>>- Add more archetypes as part of this effort. We could see a couple
>>>>of archetypes already developed, but that need to be reviewed and we 
>>>> have
>>>>to add those to the specific repo. @Inthirakumaaran
>>>>Tharmakulasingham  will share the details
>>>>on this.
>>>>- Generate guidance for creating an archetype.
>>>>
>>>> Please share your thoughts and suggestions about this effort, that will
>>>> be very helpful to us to continue on this :)
>>>>
>>>> [1] https://github.com/wso2-extensions/archetypes
>>>> <https://www.google.com/url?q=https://github.com/wso2-extensions/archetypes=D=hangouts=1564833739149000=AFQjCNFopSwDYqHH3VV8GZORIXe7CmhGTQ>
>>>>
>>>> Thanks
>>>> Kanapriya Kuleswararajan
>>>> Senior Software Engineer
>>>> Mobile : - 0774894438
>>>> Mail: - kanapr...@wso2.com
>>>> LinkedIn : - https://www.linkedin.com/in/kanapriya-kules-94712685/
>>>> WSO2, Inc.
>>>> lean. enterprise. middleware
>>>>
>>>>
>>>
>>> --
>>> *Tharindu Bandara*
>>> Software Engineer | WSO2
>>>
>>> Email : tharin...@wso2.com
>>> Mobile : +94 714221776
>>> web : http://wso2.com
>>> <https://www.google.com/url?q=http://wso2.com=D=151765338399=AFQjCNFggB4bSJTKmdqKcBV0VY9xx1ABKg>
>>>
>>> https://wso2.com/signature
>>> ___
>>> Architecture mailing list
>>> architect...@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> *S.Uthaiyashankar* | SVP Engineering | WSO2 Inc. <http://wso2.com/>
>> (M)+94 774895474 | (E) shan...@wso2.com
>> <https://wso2.com/signature>
>>
>

-- 
*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com

<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Differentiating signature algorithm in JWKS endpoint

[Inthirakumaaran Tharmakulasingham]

Hi all,

As per the offline discussions had with @Ruwan Abeykoon 
 and @Farasath Ahamed , we are going to create
different keysets for different algorithms. In order to do that we are
going to create a new KeyID generation method which combines thumbprint of
certificate and algorithm. For backward compatibility, we are adding a
keyset with thumbPrint as KeyID as well.

Thank you @Ruwan Abeykoon   and @Farasath Ahamed


Regards,
kumaaran

On Wed, May 8, 2019 at 4:42 PM Ruwan Abeykoon  wrote:

> Hi Inthi,
> My reading is that we need to expose it with following format. Same kid
> value.
>
> {
>
>- kty: "RSA",
>- e: "AQAB",
>- use: "sig",
>- kid: "ODMyNzRmOTE4NWVkMjE4NTJkNjAwYWI5YWRjODZiZGIyM2FiYWEwZg",
>- alg: "RS256",
>- n:
>
> "hIBgxdAVKh00IiY_VA6EXoQt6VaodNiwD2RFXkRu-AJn8zJ7lLs4t5tX6Cqa5UTSYXmjMvbBkOoSHiRWuEd-4X40lnm_02PrDhpuCj9EcNMmwPUHeFXxVSnw2lQ2I72KuHVx3ooWjFj7ssIM3bAnaOVlGwPj8cEL4FCgVdtd4cR2jLHyo8mk7IIYde9EYifeXluZ8knJ16y693WwaasFApvpP9Kee7AlLFhfReldWJNKNSROGKNkmX76KGcBttYh2UeALYEK5VNU0BCJx_pLwkAKka1l46eXsu78Chz3oO52AYh947YgZ_mejIvl8vN-bZogOGEalPky3JthmAsEwQ"
>
> },
> {
>
>- kty: "RSA",
>- e: "AQAB",
>- use: "sig",
>- kid: "ODMyNzRmOTE4NWVkMjE4NTJkNjAwYWI5YWRjODZiZGIyM2FiYWEwZg",
>- alg: "RS512",
>- n:
>
> "hIBgxdAVKh00IiY_VA6EXoQt6VaodNiwD2RFXkRu-AJn8zJ7lLs4t5tX6Cqa5UTSYXmjMvbBkOoSHiRWuEd-4X40lnm_02PrDhpuCj9EcNMmwPUHeFXxVSnw2lQ2I72KuHVx3ooWjFj7ssIM3bAnaOVlGwPj8cEL4FCgVdtd4cR2jLHyo8mk7IIYde9EYifeXluZ8knJ16y693WwaasFApvpP9Kee7AlLFhfReldWJNKNSROGKNkmX76KGcBttYh2UeALYEK5VNU0BCJx_pLwkAKka1l46eXsu78Chz3oO52AYh947YgZ_mejIvl8vN-bZogOGEalPky3JthmAsEwQ"
>
> },
>
>
> Excerpt:
>
>  (One
>example in which different keys might use the same "kid" value is if
>they have different "kty" (key type) values but are considered to be
>equivalent alternatives by the application using them.)
>
>
>
> Cheers,
> Ruwan A
>
> On Wed, May 8, 2019 at 4:05 PM Inthirakumaaran Tharmakulasingham <
> inthirakumaa...@wso2.com> wrote:
>
>> Hi all,
>>
>> Through the identity.xml it is possible to change the signature algorithm
>> for following JWT tokens
>>
>>
>>1. Access token
>>2. ID Token
>>3. UserInfoJWT
>>
>> It is possible to set different types of algorithms to each of the
>> tokens.
>>
>> After a token is signed and sent to the user, they can access the JWKS
>> endpoint to get the public key. In our current JWKS endpoint, we only show
>> one key set like this
>> keys:
>> [
>>
>>-
>>{
>>   - kty: "RSA",
>>   - e: "AQAB",
>>   - use: "sig",
>>   - kid: "ODMyNzRmOTE4NWVkMjE4NTJkNjAwYWI5YWRjODZiZGIyM2FiYWEwZg",
>>   - alg: "RS256",
>>   - n:
>>   
>> "hIBgxdAVKh00IiY_VA6EXoQt6VaodNiwD2RFXkRu-AJn8zJ7lLs4t5tX6Cqa5UTSYXmjMvbBkOoSHiRWuEd-4X40lnm_02PrDhpuCj9EcNMmwPUHeFXxVSnw2lQ2I72KuHVx3ooWjFj7ssIM3bAnaOVlGwPj8cEL4FCgVdtd4cR2jLHyo8mk7IIYde9EYifeXluZ8knJ16y693WwaasFApvpP9Kee7AlLFhfReldWJNKNSROGKNkmX76KGcBttYh2UeALYEK5VNU0BCJx_pLwkAKka1l46eXsu78Chz3oO52AYh947YgZ_mejIvl8vN-bZogOGEalPky3JthmAsEwQ"
>>   },
>>
>> ]
>>
>> By using this keyset, the user can create the public key and validate his
>> token. Please refer[1] to under each element in the keyset.
>>
>> Currently, we are hard-coding the value of "alg" which will be used to
>> decode the signature. But ideally, we should read the value from
>> identity.xml and expose it in the JWKS endpoint. If that the case then
>> which algorithm we should read from identity.xml? or Do we have to expose
>> different keysets for different algorithms (eg: 3 different keysets if all
>> of the above signature algorithms are different) ?
>>
>> Reference
>> [1] https://tools.ietf.org/html/rfc7517#page-8
>>
>> Thanks and Regards,
>> Kumaaran
>> --
>> *Inthirakumaaran*
>> Software Engineer | WSO2
>>
>> E-mail:inthirakumaa...@wso2.com
>> Mobile:+94775558050
>> Web:https://wso2.com
>>
>> <http://wso2.com/signature>
>>
>>
>>
>
> --
>
> *Ruwan Abeykoon*
> *Associate Director/Architect**,*
> *WSO2, Inc. http://wso2.com <https://wso2.com/signature> *
> *lean.enterprise.middleware.*
>
>

-- 
*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com

<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Differentiating signature algorithm in JWKS endpoint

[Inthirakumaaran Tharmakulasingham]

Hi all,

Through the identity.xml it is possible to change the signature algorithm
for following JWT tokens


   1. Access token
   2. ID Token
   3. UserInfoJWT

It is possible to set different types of algorithms to each of the tokens.

After a token is signed and sent to the user, they can access the JWKS
endpoint to get the public key. In our current JWKS endpoint, we only show
one key set like this
keys:
[

   -
   {
  - kty: "RSA",
  - e: "AQAB",
  - use: "sig",
  - kid: "ODMyNzRmOTE4NWVkMjE4NTJkNjAwYWI5YWRjODZiZGIyM2FiYWEwZg",
  - alg: "RS256",
  - n:
  
"hIBgxdAVKh00IiY_VA6EXoQt6VaodNiwD2RFXkRu-AJn8zJ7lLs4t5tX6Cqa5UTSYXmjMvbBkOoSHiRWuEd-4X40lnm_02PrDhpuCj9EcNMmwPUHeFXxVSnw2lQ2I72KuHVx3ooWjFj7ssIM3bAnaOVlGwPj8cEL4FCgVdtd4cR2jLHyo8mk7IIYde9EYifeXluZ8knJ16y693WwaasFApvpP9Kee7AlLFhfReldWJNKNSROGKNkmX76KGcBttYh2UeALYEK5VNU0BCJx_pLwkAKka1l46eXsu78Chz3oO52AYh947YgZ_mejIvl8vN-bZogOGEalPky3JthmAsEwQ"
  },

]

By using this keyset, the user can create the public key and validate his
token. Please refer[1] to under each element in the keyset.

Currently, we are hard-coding the value of "alg" which will be used to
decode the signature. But ideally, we should read the value from
identity.xml and expose it in the JWKS endpoint. If that the case then
which algorithm we should read from identity.xml? or Do we have to expose
different keysets for different algorithms (eg: 3 different keysets if all
of the above signature algorithms are different) ?

Reference
[1] https://tools.ietf.org/html/rfc7517#page-8

Thanks and Regards,
Kumaaran
-- 
*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Multiple keys support in JWKS endpoint

[Inthirakumaaran Tharmakulasingham]

Hi Shammi,

Thanks for the input

So, in each an every validation request step of 6, Certificate resolver has
> to send all the JWKs to JWKS endpoint or will they be cached int he JWKS
> endpoint? If we can cache them, there will be a performance improvement
> right ? However, we have to make sure the cache invalidation time out is
> there.
>

Already the keys are cached in the keystore manager and in the certificate
resolver, we will perform some validation before exposing those JWKS. I'll
look into the cache validation time out and make sure it performs as
expected.

Thanks and regards
kumaaran

*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Multiple keys support in JWKS endpoint

[Inthirakumaaran Tharmakulasingham]

Hi Hasanthi,

Thank you for asking a good question

Think of a scenario where we have a jwt signed using primary key. After we
> make the keystore to facilitate multiple keys and having certificate
> resolver, if we do a key rotation with completely new keys how can we
> validate the signature of the JWT? After the rotation the jwks endpoint
> does not contain the the keyset of old keystore right?
>

No, we will have the keysets of the old key.

This is a problem of how you do the key rotation. So we have to follow one
of the two approaches in performing the key rotation in our new
implementation to mitigate the problem you mentioned,

1. we can import the new key with a different alias and make that alias as
primary for signing and encryption. The certificate resolver will make sure
that the correct alias is used after rotation. In this case, we don't have
to remove the old key from the key store to introduce a new key. Thus we
can expose the JWKS of the old key in the endpoint until we
explicitly remove the key from the keystore. This will be the recommended
way of doing a key rotation for our new implementation.

2. Normally in keystore, we cannot introduce the new key with already
existing alias. Hence we have to delete the old key or change the alias of
it. If we are planning to use the same alias, then first we have to change
the old key's alias to a different one before importing the new key with
old alias. By changing the old key alias, we can make sure that we don't
have to remove the old key for reusing the same alias.


FYI, as far the key is in the keystore we can expose their key sets in the
JWKS endpoint.

Hope this will clarify the problem. Please ask if you have further doubt on
this.

Thanks and Regards,
kumaaran

-- 
*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] JWKS endpoint support for Key rotation

[Inthirakumaaran Tharmakulasingham]

Hi all,

Currently, we are working on a feature to support multiple JWKS in JWKS
endpoint to expose information about the old keys in the case of key
rotations

The current flow:

In order to rotate the key, the user has to create a new keystore with one
key and replace the current keystore. In the JWKS endpoint[2], parameters
of the new public key will be shown and users can generate a public key
from that to verify the signature in the tokens.


Main problem:

The user with token signed by old key pair won't be able to validate their
signature with the new key set available in the JWKS endpoint.


Expected flow:

When the user initiates the key rotation, the details of the old public key
along the new key will be shown in the JWKS endpoint for a grace period.
This feature will be supported for all the tenants and it will be an end to
end solution. The expiry time can be set by the tenant admins and after
that period the old key details will be removed from JWKS endpoint.


So far we have 2 suggestions to solve this problem

1. Add the public keys of old keypair into a DB and exposing them via JWKS
endpoint for certain time period. The public certs can be added and deleted
via the management console.
2. Make the existing keystore to support multiple key pairs and backup them
via a DB where details of each key will be securely stored. Like the
previous case, this DB can be managed by the management console. In this
approach, we will see the possibility of creating our own keystore rather
than using the Java Key Store(jks).

Please share your thought on this

Resources
[1] JWK: https://tools.ietf.org/html/rfc7517
[2] https://docs.wso2.com/display/IS570/JSON+Web+Key+Set+Endpoint

Thanks and Regards
kumaaran

-- 
*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Introspection Endpoint throws stacktrace for expired JWT token

[Inthirakumaaran Tharmakulasingham]

Hi Nila,

Sorry for the confusion, I have mentioned the stack trace in is-server(
backend). As I mentioned earlier, the user response is correct.

Thanks,
kumaaran

On Fri, Jan 18, 2019 at 3:51 PM Nilasini Thirunavukkarasu 
wrote:

> Hi Inthirakumaaran,
>
> According to the specification[1], if a token is inactive then we should
> only return *"active": false*, we should not return why the token in
> inactive.
>
>authorization server SHOULD NOT include any additional information
>>about an inactive token, including why the token is inactive
>
>
>
>
> [1] https://tools.ietf.org/html/rfc7662#section-2.2
>
> Thanks,
> Nila.
>
> On Fri, Jan 18, 2019 at 3:24 PM Inthirakumaaran Tharmakulasingham <
> inthirakumaa...@wso2.com> wrote:
>
>> Hi,
>>
>> If we validate the expired JWT token in the introspection endpoint it
>> prompts a error log with stack trace while sending the correct response to
>> the user. The detail stack trace is in [1]. This happens because we are
>> throwing an IdentityOAuth2Exception while checking the expiry time and
>> propagating to a point where we log the error with the stack trace.
>>
>> There two viable solutions to this problem.
>> 1. Creating a sub Exception extending the IdentityOAuth2Exception.
>> 2. Creating an error code for this time expiration.
>>
>> Then we can build the correct introspection response without logging the
>> stack trace if we encountered the exception or error code.
>>
>> What would be the suitable solution to tackle this problem? Is there any
>> better way to handle this?
>>
>> This problem will occur for IS servers that are
>> using identity-inbound-auth-oauth module v6.0.66 or above. The current
>> is-product in the master branch have this module.
>>
>> [1]https://github.com/wso2/product-is/issues/4319
>>
>> Thanks & Regards,
>> kumaaran
>> --
>> *Inthirakumaaran*
>> Software Engineer | WSO2
>>
>> E-mail:inthirakumaa...@wso2.com
>> Mobile:+94775558050
>> Web:https://wso2.com
>>
>> <http://wso2.com/signature>
>>
>>
>>
>
> --
> Nilasini Thirunavukkarasu
> Software Engineer - WSO2
>
> Email : nilas...@wso2.com
> Mobile : +94775241823
> Web : http://wso2.com/
>
>
> <http://wso2.com/signature>
>


-- 
*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com

<http://wso2.com/signature>
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Introspection Endpoint throws stacktrace for expired JWT token

[Inthirakumaaran Tharmakulasingham]

Hi,

If we validate the expired JWT token in the introspection endpoint it
prompts a error log with stack trace while sending the correct response to
the user. The detail stack trace is in [1]. This happens because we are
throwing an IdentityOAuth2Exception while checking the expiry time and
propagating to a point where we log the error with the stack trace.

There two viable solutions to this problem.
1. Creating a sub Exception extending the IdentityOAuth2Exception.
2. Creating an error code for this time expiration.

Then we can build the correct introspection response without logging the
stack trace if we encountered the exception or error code.

What would be the suitable solution to tackle this problem? Is there any
better way to handle this?

This problem will occur for IS servers that are
using identity-inbound-auth-oauth module v6.0.66 or above. The current
is-product in the master branch have this module.

[1]https://github.com/wso2/product-is/issues/4319

Thanks & Regards,
kumaaran
-- 
*Inthirakumaaran*
Software Engineer | WSO2

E-mail:inthirakumaa...@wso2.com
Mobile:+94775558050
Web:https://wso2.com


___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] [TokenBinding][OAuth] Need to add a sample application to IS

[Inthirakumaaran Tharmakulasingham]

Hi Thanuja,

Thanks for the info.I have sent the PR to product IS.Please find the link
for that below.

PR:https://github.com/wso2/product-is/pull/1447

Thanks

On Tue, Nov 21, 2017 at 10:08 AM, Thanuja Jayasinghe <than...@wso2.com>
wrote:

> Hi Inthirakumaaran,
>
> You need to add your sample to https://github.com/wso2/
> product-is/tree/5.x.x/modules/samples/oauth2. Please send a pull request.
>
> Thanks,
> Thanuja
>
> On Mon, Nov 20, 2017 at 3:17 PM, Inthirakumaaran Tharmakulasingham <
> inthirakumaa...@wso2.com> wrote:
>
>> Hi all,
>> I developed a sample application to send OAuth requests to IS server with
>> token binding support.Need to add that to product IS samples.
>>
>> git hub link for that application: https://github.co
>> m/inthirakumaaran/TokenBindingSample
>>
>> Thank you,
>>
>> Regards,
>> kumar
>>
>> --
>> Inthirakumaaran
>> Software Engineering - Intern | WSO2
>>
>> Email: inthirakumaa...@wso2.com
>> Mobile:0766598050
>>
>>
>
>
> --
> *Thanuja Lakmal*
> Associate Technical Lead
> WSO2 Inc. http://wso2.com/
> *lean.enterprise.middleware*
> Mobile: +94715979891
>



-- 
Inthirakumaaran
Software Engineering - Intern | WSO2

Email: inthirakumaa...@wso2.com
Mobile:0766598050
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Fwd: Anomaly Detection in JIra Using CEP

[Inthirakumaaran Tharmakulasingham]

Hi isham,

Yep, kind of, I think what you need is an SSL certificate and it contains
the public key.If put that in your key store you won't get a validator
exception... :)

On Tue, Nov 21, 2017 at 10:15 AM, Isham Mohamed <is...@wso2.com> wrote:

> Hi Kumar,
>
> Thanks for the response. That's the problem. if I was able to get access
> to the public key of the mail server I would  have done it straightforward.
> but dev_ops has some difficulty getting me the public key.
> is that what u suggested??
>
>
> On Tue, Nov 21, 2017 at 9:46 AM, Inthirakumaaran Tharmakulasingham <
> inthirakumaa...@wso2.com> wrote:
>
>> +Dev
>>
>> On Mon, Nov 20, 2017 at 11:07 PM, Inthirakumaaran Tharmakulasingham <
>> inthirakumaa...@wso2.com> wrote:
>>
>>> Hi Isham,
>>>
>>> Did you add proper certificates to Java keystore? ( $JAVA_HOME/
>>> jre/lib/security/cacerts).If you want you can run your server with
>>> "-Djavax.net.debug=all" see more about your problem.Hope this could help :)
>>>
>>> regards,
>>> kumar
>>>
>>>
>>> On Mon, Nov 20, 2017 at 5:50 PM, Isham Mohamed <is...@wso2.com> wrote:
>>>
>>>> Hi All,
>>>> This is regarding configuring email publisher of the wso2das3.1.0
>>>> I configured output-event-adapter.xml as bellow
>>>>
>>>> * *
>>>> **
>>>> *no-re...@wso2.com
>>>> <no-re...@wso2.com>*
>>>> *[username]*
>>>> *[password]*
>>>> *tygra.wso2.com
>>>> <http://tygra.wso2.com>*
>>>> *25*
>>>> *true*
>>>> *true*
>>>> **
>>>> *8*
>>>> *100*
>>>> *2*
>>>> *1*
>>>> **
>>>>
>>>> when I tried to send a mail there was an error saying,
>>>>
>>>> javax.net.ssl.SSLHandshakeException: 
>>>> sun.security.validator.ValidatorException:
>>>> PKIX path building failed: 
>>>> sun.security.provider.certpath.SunCertPathBuilderException:
>>>> unable to find valid certification path to requested target
>>>>
>>>> so we did a workaround by disabling "mail.smtp.starttls" .
>>>> The mails are used only for internal purpose.
>>>> is this recommended??
>>>>
>>>> Thanks
>>>>
>>>> On Mon, Nov 20, 2017 at 5:38 PM, Isham Mohamed <is...@wso2.com> wrote:
>>>>
>>>>> adding Srinath,Suho,Sajith,Isuru
>>>>>
>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Isham Mohamed
>>>> *Trainee Software Engineer*
>>>> WSO2
>>>>
>>>> p: +94778696585 <+94%2077%20869%206585>
>>>>
>>>> <https://lk.linkedin.com/in/isham-mohamed-890792109>.
>>>>
>>>> ___
>>>> Dev mailing list
>>>> Dev@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>>
>>>
>>>
>>> --
>>> Inthirakumaaran
>>> Software Engineering - Intern | WSO2
>>>
>>> Email: inthirakumaa...@wso2.com
>>> Mobile:0766598050
>>>
>>>
>>
>>
>> --
>> Inthirakumaaran
>> Software Engineering - Intern | WSO2
>>
>> Email: inthirakumaa...@wso2.com
>> Mobile:0766598050
>>
>>
>
>
> --
>
> Isham Mohamed
> *Trainee Software Engineer*
> WSO2
>
> p: +94778696585 <+94%2077%20869%206585>
>
> <https://lk.linkedin.com/in/isham-mohamed-890792109>.
>



-- 
Inthirakumaaran
Software Engineering - Intern | WSO2

Email: inthirakumaa...@wso2.com
Mobile:0766598050
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Fwd: Anomaly Detection in JIra Using CEP

[Inthirakumaaran Tharmakulasingham]

+Dev

On Mon, Nov 20, 2017 at 11:07 PM, Inthirakumaaran Tharmakulasingham <
inthirakumaa...@wso2.com> wrote:

> Hi Isham,
>
> Did you add proper certificates to Java keystore? ( $JAVA_HOME/
> jre/lib/security/cacerts).If you want you can run your server with
> "-Djavax.net.debug=all" see more about your problem.Hope this could help :)
>
> regards,
> kumar
>
>
> On Mon, Nov 20, 2017 at 5:50 PM, Isham Mohamed <is...@wso2.com> wrote:
>
>> Hi All,
>> This is regarding configuring email publisher of the wso2das3.1.0
>> I configured output-event-adapter.xml as bellow
>>
>> * *
>> **
>> *no-re...@wso2.com
>> <no-re...@wso2.com>*
>> *[username]*
>> *[password]*
>> *tygra.wso2.com
>> <http://tygra.wso2.com>*
>> *25*
>> *true*
>> *true*
>> **
>> *8*
>> *100*
>> *2*
>> *1*
>> **
>>
>> when I tried to send a mail there was an error saying,
>>
>> javax.net.ssl.SSLHandshakeException: 
>> sun.security.validator.ValidatorException:
>> PKIX path building failed: 
>> sun.security.provider.certpath.SunCertPathBuilderException:
>> unable to find valid certification path to requested target
>>
>> so we did a workaround by disabling "mail.smtp.starttls" .
>> The mails are used only for internal purpose.
>> is this recommended??
>>
>> Thanks
>>
>> On Mon, Nov 20, 2017 at 5:38 PM, Isham Mohamed <is...@wso2.com> wrote:
>>
>>> adding Srinath,Suho,Sajith,Isuru
>>>
>>
>>
>>
>> --
>>
>> Isham Mohamed
>> *Trainee Software Engineer*
>> WSO2
>>
>> p: +94778696585 <+94%2077%20869%206585>
>>
>> <https://lk.linkedin.com/in/isham-mohamed-890792109>.
>>
>> ___
>> Dev mailing list
>> Dev@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>>
>
>
> --
> Inthirakumaaran
> Software Engineering - Intern | WSO2
>
> Email: inthirakumaa...@wso2.com
> Mobile:0766598050
>
>


-- 
Inthirakumaaran
Software Engineering - Intern | WSO2

Email: inthirakumaa...@wso2.com
Mobile:0766598050
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] [OAuth2.0] [Token Binding] Need delimiter for security tokens

[Inthirakumaaran Tharmakulasingham]

Hi all,

In my project token binding, I need to append the hash value of token
binding Id to access token, refresh token and authorization code.For that,
I need a magic String as a delimiter to separate token binding id and
security tokens.

Eg: if you take access token with token binding support then

new access token = hash(tokenBindingID)+delimieter+normalAccessToken.

Later on, this delimiter will be used in Introspection endpoint to extract
the token binding hash value.The problem is user can configure his token
generator in IS and that generator could use special characters.So I need a
proper delimiter

Currently, I am using 

[Dev] [TokenBinding][OAuth] Need to add a sample application to IS

[Inthirakumaaran Tharmakulasingham]

Hi all,
I developed a sample application to send OAuth requests to IS server with
token binding support.Need to add that to product IS samples.

git hub link for that application:
https://github.com/inthirakumaaran/TokenBindingSample

Thank you,

Regards,
kumar

-- 
Inthirakumaaran
Software Engineering - Intern | WSO2

Email: inthirakumaa...@wso2.com
Mobile:0766598050
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

Re: [Dev] Extending BCJSSE for Token binding

[Inthirakumaaran Tharmakulasingham]

I think there is a signature verification problem when using bouncy castle
provider.You can find the details of the past problem in the link[1].(got
this problem 3 years ago)

I started the conversation with BC developers and they're not going to
implement token binding extension by them self in near future.The new
extension, they added on user request was a small one and they already
had implemented it but commented out for some reason.Details about that
extension are in this link[2].But they are okay with sending PR for token
binding implementation.If it is merged then we can reach java community
easily.More details about the conversation can be found at this link[3].

When I talked to BC providers they mentioned about an extension API which
can be used to add a new extension in the handshake.I did some digging into
that and it seems is possible to create a token binding extension and have
to put that into that API.Rest of the negotiations will be done by that
API.So currently I am in the process of developing an extension that could
fit into that API.

Reference:
  [1]Bouncy castle issue mail thread
<http://wso2-oxygen-tank.10903.n7.nabble.com/Error-bcprov-jdk15on-1-49-0-wso2v1-jar-has-unsigned-entries-org-bouncycastle-LICENSE-class-td103606.html>
  [2]https://github.com/bcgit/bc-java/issues/234
  [3]https://github.com/bcgit/bc-java/issues/250



On Fri, Nov 10, 2017 at 8:34 AM, KasunG Gajasinghe <kas...@wso2.com> wrote:

> Hi Indra,
>
> Can you find out exactly what issues we faced before? I'm assuming it has
> something to do with jar signing.
>
> The work we are doing is not specific to wso2 but applies to entire Java
> community and bouncycastle users. So, our end goal should be get this
> merged into bouncycastle project.
>
> Please start a dialogue with BC developers asap. They are on GitHub now I
> suppose.
>
> Bouncycastle just added a new tls extension last month, and the community
> quite active.
>
> @Prabath, please share your thoughts.
>
> Thanks,
> KasunG
>
> On Thu, Nov 9, 2017 at 2:10 PM Inthirakumaaran Tharmakulasingham <
> inthirakumaa...@wso2.com> wrote:
>
>> Hi,
>> I am trying to create a Token binding library for TLS layer.One option
>> for this to extend BCJSSE and write the implementations on top of it.But in
>> the past, there have been some issues in making changes in Bouncy
>> Castle.How can I proceed with this?OR any better way to write the library?
>>
>> Basically, our intention is to make a token binding library so that
>> anyone can create HTTP client which can support token binding.Thus we hope
>> to send a PR to BC after completing the implementation.
>>
>>
>> --
>> Inthirakumaaran
>> Software Engineering - Intern | WSO2
>>
>> Email: inthirakumaa...@wso2.com
>> Mobile:0766598050
>>
>> --
>
> *Kasun Gajasinghe*Associate Technical Lead, WSO2 Inc.
> email: kasung AT spamfree wso2.com
> linked-in: http://lk.linkedin.com/in/gajasinghe
> blog: http://kasunbg.org
> phone: +1 650-745-4499 <(650)%20745-4499>, 77 678 0813
>
>



-- 
Inthirakumaaran
Software Engineering - Intern | WSO2

Email: inthirakumaa...@wso2.com
Mobile:0766598050
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev

[Dev] Extending BCJSSE for Token binding

[Inthirakumaaran Tharmakulasingham]

Hi,
I am trying to create a Token binding library for TLS layer.One option for
this to extend BCJSSE and write the implementations on top of it.But in the
past, there have been some issues in making changes in Bouncy Castle.How
can I proceed with this?OR any better way to write the library?

Basically, our intention is to make a token binding library so that anyone
can create HTTP client which can support token binding.Thus we hope to send
a PR to BC after completing the implementation.

-- 
Inthirakumaaran
Software Engineering - Intern | WSO2

Email: inthirakumaa...@wso2.com
Mobile:0766598050
___
Dev mailing list
Dev@wso2.org
http://wso2.org/cgi-bin/mailman/listinfo/dev