Re: [Architecture] WSO2 Identity Server REST API Error Response Standardization

[Sathya Bandara]

gt;>>>> Therefore, we would like to maintain the error codes which are used
>>>>>> in our REST APIs in one commonplace. Currently, we are standardizing 
>>>>>> error
>>>>>> codes along with their details and this is still a work in progress.
>>>>>>
>>>>>> According to this effort, sample error code will look like “
>>>>>> -
>>>>>>
>>>>>> Eg: CQM-10005
>>>>>>
>>>>>> The Prefix (first part) indicates the component. In this case, CQM
>>>>>> indicates Challenge Questions Management.
>>>>>> The error-identifier-number (the second part of the error code)
>>>>>> reflects the numerical identifier for the error.
>>>>>>
>>>>>> For the rest APIs, we have defined 2 types of codes for both user and
>>>>>> server APIs.
>>>>>>
>>>>>>-
>>>>>>
>>>>>>Success codes: For successful operations
>>>>>>-
>>>>>>
>>>>>>Error codes: For error scenarios
>>>>>>-
>>>>>>
>>>>>>   Client Errors
>>>>>>   -
>>>>>>
>>>>>>   Server Errors
>>>>>>
>>>>>>
>>>>>>
>>>>>> *Success Codes*
>>>>>>
>>>>>> Despite the API type, all the success codes will start from 02000
>>>>>> onwards. To maintain consistency, a zero will be added at the beginning.
>>>>>>
>>>>>> Eg: USR-02001
>>>>>>
>>>>>> The above Success Code indicates a successful User Self Registration.
>>>>>>
>>>>>>
>>>>>> *Error Codes*
>>>>>>
>>>>>> With the introduction of API error standards, we wish to standardize
>>>>>> the error response from an API. Therefore, a sample API error response 
>>>>>> will
>>>>>> be as follows.
>>>>>>
>>>>>> {
>>>>>>
>>>>>> “code” : “some_error_code”,
>>>>>>
>>>>>> “Message” : “some_error_message”,
>>>>>>
>>>>>> “Description” : “some_error_description”,
>>>>>>
>>>>>> “traceID” : “correlation_id”
>>>>>>
>>>>>> }
>>>>>>
>>>>>> A correlationId has been introduced to log the error and send with
>>>>>> the response
>>>>>>
>>>>>>
>>>>>> *User API errors*
>>>>>>
>>>>>> User APIs has two types of errors.
>>>>>>
>>>>>>1.
>>>>>>
>>>>>>Client errors
>>>>>>2.
>>>>>>
>>>>>>Server errors
>>>>>>
>>>>>> *Client Errors in user APIs*
>>>>>>
>>>>>> For client errors in user APIs, we have allocated the range starting
>>>>>> from 100.
>>>>>>
>>>>>> Eg: USR-100xx
>>>>>>
>>>>>> *Server Errors in user APIs*
>>>>>>
>>>>>> For server errors in user APIs, we have allocated the range starting
>>>>>> from 100.
>>>>>>
>>>>>> Eg: USR-150xx
>>>>>>
>>>>>>
>>>>>> *Server API Errors*
>>>>>>
>>>>>> Server APIs has two types of errors.
>>>>>>
>>>>>>1.
>>>>>>
>>>>>>Client errors
>>>>>>2.
>>>>>>
>>>>>>Server errors
>>>>>>
>>>>>> *Client errors in server APIs*
>>>>>>
>>>>>> For client errors in server APIs, we have allocated the range
>>>>>> starting from 500.
>>>>>>
>>>>>> Eg: USR-500xx
>>>>>>
>>>>>> *Server Errors in server APIs*
>>>>>>
>>>>>> For server errors in server APIs, we have allocated the range
>>>>>> starting from 550.
>>>>>>
>>>>>> Eg: USR-550xx
>>>>>>
>>>>>>
>>>>>> This will be the new standardization for Rest API Success and Error
>>>>>> responses.
>>>>>>
>>>>>>
>>>>>> Thanks & Regards,
>>>>>>
>>>>>> Sominda.
>>>>>>
>>>>>> --
>>>>>> *Sominda Gamage* | Software Engineer| WSO2 Inc. <http://wso2.com/>
>>>>>> (M)+94 719873902 | (E) somi...@wso2.com
>>>>>> <https://wso2.com/signature>
>>>>>> ___
>>>>>> Architecture mailing list
>>>>>> Architecture@wso2.org
>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> *Isura Dilhara Karunaratne*
>>>>> Technical Lead | WSO2 <http://wso2.com/>
>>>>> *lean.enterprise.middleware*
>>>>> Email: is...@wso2.com
>>>>> Mob : +94 772 254 810
>>>>> Blog : https://medium.com/@isurakarunaratne
>>>>>
>>>>>
>>>>>
>>>>> ___
>>>>> Architecture mailing list
>>>>> Architecture@wso2.org
>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> Vihanga Liyanage
>>>>
>>>> Senior Software Engineer | WS*O₂* Inc.
>>>>
>>>> M : +*94710124103* | http://wso2.com
>>>>
>>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>>>
>>>
>>>
>>> --
>>>
>>> Vihanga Liyanage
>>>
>>> Senior Software Engineer | WS*O₂* Inc.
>>>
>>> M : +*94710124103* | http://wso2.com
>>>
>>> [image: http://wso2.com/signature] <http://wso2.com/signature>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> *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
>>
>
>
> --
> Regards,
>
>
> *Darshana Gunawardana*Technical Lead
> WSO2 Inc.; http://wso2.com
>
> *E-mail: darsh...@wso2.com *
> *Mobile: +94718566859*Lean . Enterprise . Middleware
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] REST API to retrieve docs for the side panel guide in developer portal

[Sathya Bandara]

Hi all,

We are in the process of implementing a side panel help guide in the dev
portal which will show a preview of related documents to the user as he
navigates through the dev portal. More info on this can be found in [1].

Originally we thought to use Github REST API to retrieve the docs and its
sitemap. However when accessing the Github API, it has a rate limit of 60
requests per hour for unauthenticated requests [2].

We had a discussion with the team and as a solution to this limitation, we
decided to introduce a new server API. In the API we will use OAuth based
authentication to Github which increases the rate limit to to 5000
requests/hour.

Following will be the notations of the new API


** GET api/server/v1/docs/sitemap*
This will return the entire sitemap for WSO2 Documentation. If it is
required to retrieve the sitemap for a particular portal, we have added the
support to specify it in a query param.
E.g.


*api/server/v1/docs/sitemap?portal=Dev+Portal*

** POST api/server/v1/docs*
This will be the API to retrieve docs. Here we need to pass any key
retrieved from the sitemap in the request body, in-order to retrieve the
document corresponding to that key.

Highly appreciate your thoughts and suggestions.

[1] "[Iam-dev] [Dev Portal] [UX] Side panel design for the WSO2 Identity
Server Developer Portal"
[2] https://developer.github.com/v3/#rate-limiting

Thanks,
Sathya
-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Iam-dev] REST API to Retrieve Resident IDP/SP Specific Properties

[Sathya Bandara]

Hi Ayesha,

Thank you for the suggestions. I'm +1 for the 1st approach as it is
providing all the server configs in a single call instead of requiring the
client to perform multiple calls. I have introduced slight modifications to
the inbound config. Please see the final configs model and let me know what
you think.

{
  "homeRealmIdentifiers": [
"localhost"
  ],
  "idleSessionTimeoutPeriod": "15",
  "rememberMePeriod": "20160",
  "provisioning": {
"inbound": {
  "scim": {
"provisioningUserstore": "PRIMARY",
"enableDumbMode": false
  }
}
  },
  "authenticators": [
{
  "id": "QmFzaWNBdXRoZW50aWNhdG9y",
  "name": "BasicAuthenticator",
  "displayName": "basic",
  "isEnabled": true,
  "self": 
"/t/carbon.super/api/server/v1/configs/authenticators/QmFzaWNBdXRoZW50aWNhdG9y"
}
  ]}

With this new approach, instead of giving PUT operation support for the
/configs resource, shall we give PATCH operation for root level attributes
in configs API, and PUT for sub-level provisioning resource? WDYT?


On Mon, Apr 20, 2020 at 12:39 PM Ayesha Dissanayaka  wrote:

> Hi Sathya,
>
> What if api/server/v1/configs returns everything like below.
>
> {
>   "homeRealmIdentifier": [
> "localhost"
>   ],
>   "idleSessionTimeoutPeriod": "15",
>   "rememberMePeriod": "20160",
>   "provisioning" : {
>  "inbound" : {
>  "provisioningUserstore": "PRIMARY",
>  "enableDumbMode": false
>   }
>},
>   "authenticators": [
>   {
> "id": "QmFzaWNBdXRoZW50aWNhdG9y",
> "name": "BasicAuthenticator",
> "displayName": "basic",
> "isEnabled": true,
> "self":
> "/t/carbon.super/api/server/v1/configs/authenticators/QmFzaWNBdXRoZW50aWNhdG9y"
>   }
>  ]
> }
>
> Or  give links like below
>
> {
>
>   "homeRealmIdentifier": [
> "localhost"
>   ],
>   "idleSessionTimeoutPeriod": "15",
>   "rememberMePeriod": "20160",
>   "provisioning" : {
>
>  "link": ""
>
>},
>   "authenticators": {
>
>  "link": ""
>
>}
> }
>
>
> Then to manage sub-content use
>
> api/server/v1/configs/provisioning
>
> api/server/v1/configs/authenticators
>
> Thanks!
> -Ayesha
>
> On Fri, Apr 17, 2020 at 5:58 PM Sathya Bandara  wrote:
>
>> Hi all,
>>
>> Currently in Identity Server, we do not have a capability to retrieve
>> following resident configurations in a restful manner.
>>
>> *Resident IDP*
>>
>>- Home realm identifier
>>- Idle session timeout
>>- Remember me period
>>
>> *Resident SP*
>>
>> As a solution to this we have decided to introduce a new API under the
>> existing *t/carbon.super/api/server/v1/configs* context in order to
>> retrieve and update those configs.
>>
>> *For resident IDP related properties*
>>
>> *API Context*
>> api/server/v1/configs/realm
>>
>> *Model*
>>
>> {
>>   "homeRealmIdentifier": [
>> "localhost"
>>   ],
>>   "idleSessionTimeoutPeriod": "15",
>>   "rememberMePeriod": "20160"}
>>
>> *Supported operations*
>> GET, PUT
>>
>> *For resident SP related properties*
>>
>> *API Context*
>> api/server/v1/configs/inbound/scim
>>
>> *Model*
>>
>>
>> *{ "provisioningUserstore": "PRIMARY", "enableDumbMode": false }*
>> *Supported operations*
>> GET, PUT
>>
>> Complete swagger definition can be found in [1]
>>
>> Highly appreciate your suggestions and concerns regarding this.
>>
>> [1] https://app.swaggerhub.com/apis/emswbandara/IAM_CONFIGS/0.1.0#/
>>
>> Thanks,
>> --
>> Sathya Bandara
>> Senior Software Engineer
>> Blog: https://medium.com/@technospace
>> WSO2 Inc. http://wso2.com
>> Mobile: (+94) 715 360 421
>>
>> <+94%2071%20411%205032>
>> ___
>> Iam-dev mailing list
>> iam-...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>>
>
>
> --
> *Ayesha Dissanayaka*
> Technical Lead
> WSO2, Inc: http://wso2.com
> <http://www.google.com/url?q=http%3A%2F%2Fwso2.com=D=1=AFQjCNEZvyc0uMD1HhBaEGCBxs6e9fBObg>
> 20, Palm Grove Avenue, Colombo 3
> E-Mail: aye...@wso2.com 
> Mobile: +94713580922
>


-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] REST API to Retrieve Resident IDP/SP Specific Properties

[Sathya Bandara]

Hi all,

Currently in Identity Server, we do not have a capability to retrieve
following resident configurations in a restful manner.

*Resident IDP*

   - Home realm identifier
   - Idle session timeout
   - Remember me period

*Resident SP*

As a solution to this we have decided to introduce a new API under the
existing *t/carbon.super/api/server/v1/configs* context in order to
retrieve and update those configs.

*For resident IDP related properties*

*API Context*
api/server/v1/configs/realm

*Model*

{
  "homeRealmIdentifier": [
"localhost"
  ],
  "idleSessionTimeoutPeriod": "15",
  "rememberMePeriod": "20160"}

*Supported operations*
GET, PUT

*For resident SP related properties*

*API Context*
api/server/v1/configs/inbound/scim

*Model*


*{ "provisioningUserstore": "PRIMARY", "enableDumbMode": false }*
*Supported operations*
GET, PUT

Complete swagger definition can be found in [1]

Highly appreciate your suggestions and concerns regarding this.

[1] https://app.swaggerhub.com/apis/emswbandara/IAM_CONFIGS/0.1.0#/

Thanks,
-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Iam-dev] [iam-dev][IAM][5.11.0] REST API for Identity Provider Template Management

[Sathya Bandara]

On Sat, Mar 28, 2020 at 2:00 AM Janak Amarasena  wrote:

> Hi Mevan,
>
> In the swagger, I saw that there is a POST call with content-type support
> for application/*xml *as well in addition to application/json. Why do we
> need to have an *xml *content-type support?
>
Since we decided to support xml content type for IDP REST API, we thought
to provide the same capability when creating IDP templates as well.

>
> Best Regards,
> Janak
>
> On Mon, Mar 23, 2020 at 5:17 PM Mevan Karunanayake  wrote:
>
>> Hi all,
>>
>> I am currently working on introducing a REST API to manage identity
>> provider templates. Identity Provider Template Management API is a new
>> improvement to Identity Provider Management REST API [1] to keep frequently
>> used identity provider configurations as templates. TemplateManager [2]
>> backend OSGi service has been used to list, retrieve, add, update and
>> delete identity provider templates.
>>
>> In order to cater the API requirements, following changes were introduced
>> to TemplateManager OSGi service. You can find the PR in [3].
>>
>>- Introduce four default method definitions to TemplateManager
>>interface
>>   - update, delete and retrieve templates by ID
>>   - list templates using template types.
>>- Use existing ConfigurationManager [4] OSGi service to implement
>>TemplateManagerService.
>>- Add new method definitions to ConfigurationManager service.
>>   - retrieve and delete resources by ID.
>>
>> Defined API endpoints are as follows;
>>
>>- API endpoint for listing identity provider templates and creating
>>API templates
>>
>> *api/server/v1/identity-providers/templates*
>>
>>
>>- API to retrieve, update and delete identity provider templates by
>>ID.
>>
>> *api/server/v1/identity-providers/templates/{template-id}*
>>
>>
>> You can find the swagger definition for above endpoints in [5].
>>
>> Highly appreciate your thoughts on this.
>>
>> *References*
>> [1] https://app.swaggerhub.com/apis/emswbandara/IAM_IDP/0.1.1
>> [2]
>> https://github.com/wso2/carbon-identity-framework/blob/master/components/template-mgt/org.wso2.carbon.identity.template.mgt/src/main/java/org/wso2/carbon/identity/template/mgt/TemplateManager.java
>> [3] https://github.com/wso2/carbon-identity-framework/pull/2827
>> [4]
>> https://github.com/wso2/carbon-identity-framework/blob/master/components/configuration-mgt/org.wso2.carbon.identity.configuration.mgt.core/src/main/java/org/wso2/carbon/identity/configuration/mgt/core/ConfigurationManager.java
>> [5]
>> https://app.swaggerhub.com/apis/emswbandara/IAM_IDP/0.1.1#/Template%20management/getIDPTemplates
>>
>> Regards,
>> --
>> *Mevan Karunanayake* | Software Engineer | WSO2 Inc.
>> (m) +94712028954 | (e) me...@wso2.com
>> <https://wso2.com/signature>
>> ___
>> Iam-dev mailing list
>> iam-...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>>
>
>
> --
> *Janak Amarasena* | Senior Software Engineer | WSO2 Inc.
> (m) +9464144 | (w) +94112145345 | (e) ja...@wso2.com
>
>
> <https://wso2.com/signature>
> ___
> Iam-dev mailing list
> iam-...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>


-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM][5.11.0] REST API For Identity Server Local Authenticators

[Sathya Bandara]

Hi all,

Shall we finalize the resource context for this API since it is blocking
the implementation?

Thanks,

On Wed, Mar 18, 2020 at 12:56 PM Sathya Bandara  wrote:

> Hi Ruwan,
>
> The API will have the tenant scope however currently the authenticator
> configurations needs to be done globally using the
> application-authentication.xml file. In the future we can provide database
> support for storing tenant wise authenticator configurations.
>
> On Wed, Mar 18, 2020 at 12:41 PM Ruwan Abeykoon  wrote:
>
>> Hi Thanuja,
>> These API needs to be functional on tenant scope too, and the
>> "Authenticator" configuration needs to be done per each tenant.
>> If not we have to add the capability to configure the authentication per
>> each tenant in future quite soon.
>>
>> Cheers,
>> Ruwan A
>>
>> On Wed, Mar 18, 2020 at 12:08 PM Thanuja Jayasinghe 
>> wrote:
>>
>>> Hi Ruwan,
>>>
>>>
>>> On Wed, Mar 18, 2020 at 9:36 AM Ruwan Abeykoon  wrote:
>>>
>>>> Hi Sathya,
>>>> If this is only used for authenticating SOAP calls, then we need not
>>>> worry about managing it with REST.
>>>> SOAP services is going to be deprecated in favor of REST API. It is all
>>>> right to keep file based config and/or SOAP services to manage this.
>>>>
>>>
>>> The purpose of this API is not to provide authentication for SOAP calls,
>>> rather it is designed to fulfill the following limitations with local
>>> authenticators and related properties,
>>>  - No API to return basic attributes of a local authenticator (ex:
>>> whether the basic authenticator is enabled)
>>>  - Can't create and manage multiple instances of a local
>>> authenticator (ex: If we take Facebook federated authenticator, we can
>>> create multiple instances with different configurations by creating
>>> multiple IdPs, but this option is not available for local authenticators.)
>>>   - No API to update server own configurations for authentication,
>>> etc.(ex: session idle time for the tenant)
>>>
>>> As the first step, we are creating this API to get the basic attributes
>>> of local authenticators and it is essential for the new developer portal.
>>>
>>>
>>>>
>>>> Also, it is generally not a good idea to have API or Services to change
>>>> "configs". Configs only to be done via file system.
>>>> API is needed to change runtime data, in our case (SP, IdP, UserStore,
>>>> etc)
>>>>
>>>
>>> As this manages local authenticators(in future) and related properties,
>>> it will be run-time data. But yes, "configs" doesn't seem to be matched
>>> with the purpose.
>>>
>> Highly appreciate your suggestions for the context of this API. We have
> evaluated following options as well in addition to "configs".
>
>- resident
>- local-identity-provider
>
>
>
>>>
>>>>
>>>> Cheers,
>>>> Ruwan A
>>>>
>>>>
>>>> On Wed, Mar 18, 2020 at 9:20 AM Sathya Bandara  wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> WSO2 Identity Server currently supports server local authenticator
>>>>> related operations using SOAP APIs. I'm currently working on introducing a
>>>>> REST API layer for this purpose in 5.11.0. In the initial phase only GET
>>>>> operations will be supported in the API level since we do not allow to
>>>>> add/update local authenticators from the backend OSGi service.
>>>>>
>>>>>- API for listing authenticators
>>>>>
>>>>>
>>>>> * api/server/v1/configs/authenticators *
>>>>>- API to retrieve authenticator by ID
>>>>> * api/server/v1/configs/authenticators/{authenticator-id}*
>>>>>
>>>>> Please find the complete API definition in [1].
>>>>>
>>>>> Furthermore, since currently we do not have a REST API for managing
>>>>> configurations available under the Resident IDP section e.g. idle session
>>>>> timeout, going forward, we can introduce new APIs under
>>>>> api/server/v1/configs context.
>>>>>
>>>>> Highly appreciate your valuable suggestions on this.
>>>>>
>>>>> [1] https://app.swaggerhub.com/apis/emswbandara/IAM_CONFIGS/0.1.0
>>>>>
>>>>&

Re: [Architecture] [IAM][5.11.0] REST API For Identity Server Local Authenticators

[Sathya Bandara]

Hi Ruwan,

The API will have the tenant scope however currently the authenticator
configurations needs to be done globally using the
application-authentication.xml file. In the future we can provide database
support for storing tenant wise authenticator configurations.

On Wed, Mar 18, 2020 at 12:41 PM Ruwan Abeykoon  wrote:

> Hi Thanuja,
> These API needs to be functional on tenant scope too, and the
> "Authenticator" configuration needs to be done per each tenant.
> If not we have to add the capability to configure the authentication per
> each tenant in future quite soon.
>
> Cheers,
> Ruwan A
>
> On Wed, Mar 18, 2020 at 12:08 PM Thanuja Jayasinghe 
> wrote:
>
>> Hi Ruwan,
>>
>>
>> On Wed, Mar 18, 2020 at 9:36 AM Ruwan Abeykoon  wrote:
>>
>>> Hi Sathya,
>>> If this is only used for authenticating SOAP calls, then we need not
>>> worry about managing it with REST.
>>> SOAP services is going to be deprecated in favor of REST API. It is all
>>> right to keep file based config and/or SOAP services to manage this.
>>>
>>
>> The purpose of this API is not to provide authentication for SOAP calls,
>> rather it is designed to fulfill the following limitations with local
>> authenticators and related properties,
>>  - No API to return basic attributes of a local authenticator (ex:
>> whether the basic authenticator is enabled)
>>  - Can't create and manage multiple instances of a local
>> authenticator (ex: If we take Facebook federated authenticator, we can
>> create multiple instances with different configurations by creating
>> multiple IdPs, but this option is not available for local authenticators.)
>>   - No API to update server own configurations for authentication,
>> etc.(ex: session idle time for the tenant)
>>
>> As the first step, we are creating this API to get the basic attributes
>> of local authenticators and it is essential for the new developer portal.
>>
>>
>>>
>>> Also, it is generally not a good idea to have API or Services to change
>>> "configs". Configs only to be done via file system.
>>> API is needed to change runtime data, in our case (SP, IdP, UserStore,
>>> etc)
>>>
>>
>> As this manages local authenticators(in future) and related properties,
>> it will be run-time data. But yes, "configs" doesn't seem to be matched
>> with the purpose.
>>
> Highly appreciate your suggestions for the context of this API. We have
evaluated following options as well in addition to "configs".

   - resident
   - local-identity-provider



>>
>>>
>>> Cheers,
>>> Ruwan A
>>>
>>>
>>> On Wed, Mar 18, 2020 at 9:20 AM Sathya Bandara  wrote:
>>>
>>>> Hi all,
>>>>
>>>> WSO2 Identity Server currently supports server local authenticator
>>>> related operations using SOAP APIs. I'm currently working on introducing a
>>>> REST API layer for this purpose in 5.11.0. In the initial phase only GET
>>>> operations will be supported in the API level since we do not allow to
>>>> add/update local authenticators from the backend OSGi service.
>>>>
>>>>- API for listing authenticators
>>>>
>>>>
>>>> * api/server/v1/configs/authenticators *
>>>>- API to retrieve authenticator by ID
>>>> * api/server/v1/configs/authenticators/{authenticator-id}*
>>>>
>>>> Please find the complete API definition in [1].
>>>>
>>>> Furthermore, since currently we do not have a REST API for managing
>>>> configurations available under the Resident IDP section e.g. idle session
>>>> timeout, going forward, we can introduce new APIs under
>>>> api/server/v1/configs context.
>>>>
>>>> Highly appreciate your valuable suggestions on this.
>>>>
>>>> [1] https://app.swaggerhub.com/apis/emswbandara/IAM_CONFIGS/0.1.0
>>>>
>>>> Thanks,
>>>> Sathya
>>>> --
>>>> Sathya Bandara
>>>> Senior Software Engineer
>>>> Blog: https://medium.com/@technospace
>>>> WSO2 Inc. http://wso2.com
>>>> Mobile: (+94) 715 360 421
>>>>
>>>> <+94%2071%20411%205032>
>>>>
>>>
>>>
>>> --
>>> Ruwan Abeykoon | Director/Architect | WSO2 Inc.
>>> (w) +947435800  | Email: ruw...@wso2.com
>>>
>>>
>> Thanks,
>> Thanuja
>> --
>> *Thanuja Lakmal*
>> Technical Lead
>> WSO2 Inc. http://wso2.com/
>> *lean.enterprise.middleware*
>> Mobile: +94715979891
>>
>
>
> --
> Ruwan Abeykoon | Director/Architect | WSO2 Inc.
> (w) +947435800  | Email: ruw...@wso2.com
>
>

-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IAM][5.11.0] REST API For Identity Server Local Authenticators

[Sathya Bandara]

Hi all,

WSO2 Identity Server currently supports server local authenticator related
operations using SOAP APIs. I'm currently working on introducing a REST API
layer for this purpose in 5.11.0. In the initial phase only GET operations
will be supported in the API level since we do not allow to add/update
local authenticators from the backend OSGi service.

   - API for listing authenticators


* api/server/v1/configs/authenticators *
   - API to retrieve authenticator by ID
* api/server/v1/configs/authenticators/{authenticator-id}*

Please find the complete API definition in [1].

Furthermore, since currently we do not have a REST API for managing
configurations available under the Resident IDP section e.g. idle session
timeout, going forward, we can introduce new APIs under
api/server/v1/configs context.

Highly appreciate your valuable suggestions on this.

[1] https://app.swaggerhub.com/apis/emswbandara/IAM_CONFIGS/0.1.0

Thanks,
Sathya
-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Iam-dev] [VOTE] Release WSO2 Identity Server 5.10.0 RC2

[Sathya Bandara]

closed=1>
>>>>- 5.10.0-Beta
>>>><https://github.com/wso2/product-is/milestone/107?closed=1>
>>>>- 5.10.0-Beta2
>>>><https://github.com/wso2/product-is/milestone/108?closed=1>
>>>>- 5.10.0-Beta3
>>>><https://github.com/wso2/product-is/milestone/109?closed=1>
>>>>- 5.10.0-GA
>>>><https://github.com/wso2/product-is/milestone/92?closed=1>
>>>>
>>>>
>>>> *Source and Distribution*
>>>> The source and distribution
>>>> <https://github.com/wso2/product-is/releases/download/v5.10.0-rc2/wso2is-5.10.0-rc2.zip>
>>>>  are
>>>> available at
>>>> https://github.com/wso2/product-is/releases/tag/v5.10.0-rc2
>>>>
>>>>
>>>> Please download the product, test it, and vote using the following
>>>> convention.
>>>> [+] Stable - go ahead and release
>>>> [-] Broken - do not release (explain why)
>>>>
>>>>
>>>> Thank you,
>>>> WSO2 Identity and Access Management Team
>>>>
>>>> --
>>>> *Janak Amarasena* | Senior Software Engineer | WSO2 Inc.
>>>> (m) +9464144 | (w) +94112145345 | (e) ja...@wso2.com
>>>>
>>>>
>>>> <https://wso2.com/signature>
>>>> ___
>>>> Iam-dev mailing list
>>>> iam-...@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>>>>
>>>
>>>
>>> --
>>> *Theviyanthan Krishnamohan (Thivi)*
>>> Software Engineer | WSO2 Inc.
>>> Mobile: 94 76 967
>>> Email: theviyant...@wso2.com
>>>
>>> ___
>>> Iam-dev mailing list
>>> iam-...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>>>
>>
>>
>> --
>> *Brion Silva* | Software Engineer | WSO2 Inc.
>> (m) +94777933830 | (e) br...@wso2.com
>>
>> <https://wso2.com/signature>
>> ___
>> Iam-dev mailing list
>> iam-...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>>
> ___
> Iam-dev mailing list
> iam-...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/iam-dev
>


-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
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
>> <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
>> <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":&q

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

[Sathya Bandara]

t;> decided that enabling this feature will solely depend on the server
>>>>> configuration and we will not be checking on the availability of
>>>>> "verifyEmail" attribute in the SCIM request.
>>>>>
>>>>> Thanks,
>>>>> Dewni
>>>>>
>>>>> On Mon, Jan 20, 2020 at 7:29 AM Malithi Edirisinghe 
>>>>> wrote:
>>>>>
>>>>>>
>>>>>>
>>>>>> 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 <
>>>>>>> malit...@wso2.com> wrote:
>>>>>>>
>>>>>>>> Hi Johann,
>>>>>>>>
>>>>>>>> On Wed, Jan 8, 2020 at 4:49 AM Ajanthan Balachandran <
>>>>>>>> ajant...@wso2.com> 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
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Dewni Weeraman | Software Engineer | WSO2 Inc.
>>>>> (m) +94 077 2979049 | (e) de...@wso2.com 
>>>>>
>>>>> <http://wso2.com/signature>
>>>>>
>>>>>
>>>>>
>>>>
>>>> --
>>>> Ruwan Abeykoon | Director/Architect | WSO2 Inc.
>>>> (w) +947435800  | Email: ruw...@wso2.com
>>>>
>>>>
>>> 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
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>
>>
>> --
>> Godwin Amila Shrimal | Technical Lead | WSO2 Inc.
>> (m) +44 744 466 3849 | (w) +44 203 696 6510 | (e) god...@wso2.com
>> <http://wso2.com/signature>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>
>
> --
> Dewni Weeraman | Software Engineer | WSO2 Inc.
> (m) +94 077 2979049 | (e) de...@wso2.com 
>
> <http://wso2.com/signature>
>
>
>

-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IAM][IS 5.10.0] REST APIs For Identity Provider Management

[Sathya Bandara]

Hi Frank,

As we support PUT operation on all the sub-resources of the
/identity-provider, we decided to support PATCH operation only for the root
level attributes of IDP.. e.g IDP name, certificate etc. Please find the
updated swagger definition in [1]. IMO, it is not convenient to ask the
user to send a PUT request to update a frequently updated attribute such as
IDP certificate. WDYT?

[1] https://app.swaggerhub.com/apis/emswbandara/IAM_IDP/0.1.0-oas3

On Sat, Nov 2, 2019 at 7:00 PM Frank Leymann  wrote:

> Hi Sathya,
>
> you support PATCH for the
> resource /identity-providers/{identity-provider-id}  but for none of the
> other resources: any reason for this?  Don't get me wrong, the less we
> support PATCH the better ;-)
>
> Best regards,
> Frank
>
>
>
>
> Am Sa., 2. Nov. 2019 um 06:24 Uhr schrieb Sathya Bandara  >:
>
>> Hi all,
>>
>> WSO2 Identity Server currently supports IDP related operations using SOAP
>> APIs. I'm currently working on introducing a REST API layer for IDP
>> management in 5.10.0. Please find the API definition in [1].
>>
>> The internal implementation for the above APIs will use the
>> IdentityProviderManager[2] OSGi service. As per the team discussions, we
>> have introduced the following framework level changes to support RESTful
>> operations for the IDPs.
>>
>>- Introduce UUID, Image URL to identity provider model.
>>- Change DDL of IDP table to store UUID and Image URL.
>>- Introduce Regex, Options and SubProperties to Property model.
>>- Introduce OSGi methods and DAO layer methods to do IDP operations
>>with resource ID (UUID).
>>- Listeners for IDP operations based on resource ID.
>>
>> [1] https://app.swaggerhub.com/apis/emswbandara/IAM_IDP/0.1.0
>>
>> Highly appreciate your valuable suggestions.
>>
>> Thanks,
>> Sathya
>> --
>> Sathya Bandara
>> Senior Software Engineer
>> Blog: https://medium.com/@technospace
>> WSO2 Inc. http://wso2.com
>> Mobile: (+94) 715 360 421
>>
>> <+94%2071%20411%205032>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>


-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IAM][IS 5.10.0] REST APIs For Identity Provider Management

[Sathya Bandara]

Hi all,

WSO2 Identity Server currently supports IDP related operations using SOAP
APIs. I'm currently working on introducing a REST API layer for IDP
management in 5.10.0. Please find the API definition in [1].

The internal implementation for the above APIs will use the
IdentityProviderManager[2] OSGi service. As per the team discussions, we
have introduced the following framework level changes to support RESTful
operations for the IDPs.

   - Introduce UUID, Image URL to identity provider model.
   - Change DDL of IDP table to store UUID and Image URL.
   - Introduce Regex, Options and SubProperties to Property model.
   - Introduce OSGi methods and DAO layer methods to do IDP operations with
   resource ID (UUID).
   - Listeners for IDP operations based on resource ID.

[1] https://app.swaggerhub.com/apis/emswbandara/IAM_IDP/0.1.0

Highly appreciate your valuable suggestions.

Thanks,
Sathya
-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

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

[Sathya Bandara]

   -
>>>>>>>
>>>>>>>Inbuilt support to view and revoke user sessions
>>>>>>>-
>>>>>>>
>>>>>>>Azure AD/Office365 multi-domain federation support
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Fixes
>>>>>>>
>>>>>>> This release includes the following issue fixes and improvements:
>>>>>>>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-m1
>>>>>>><https://github.com/wso2/product-is/milestone/85?closed=1>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-m2
>>>>>>><https://github.com/wso2/product-is/milestone/86?closed=1>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-m3
>>>>>>><https://github.com/wso2/product-is/milestone/87?closed=1>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-m4
>>>>>>><https://github.com/wso2/product-is/milestone/88?closed=1>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-m5
>>>>>>><https://github.com/wso2/product-is/milestone/90?closed=1>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-m6
>>>>>>><https://github.com/wso2/product-is/milestone/91?closed=1>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-alpha
>>>>>>><https://github.com/wso2/product-is/milestone/89?closed=1>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-beta
>>>>>>><https://github.com/wso2/product-is/milestone/93?closed=1>
>>>>>>>-
>>>>>>>
>>>>>>>5.9.0-GA
>>>>>>><https://github.com/wso2/product-is/milestone/83?closed=1>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Source and Distribution
>>>>>>>
>>>>>>> The source and distribution
>>>>>>> <https://github.com/wso2/product-is/releases/download/v5.9.0-rc2/wso2is-5.9.0-rc2.zip>
>>>>>>> are available at
>>>>>>> https://github.com/wso2/product-is/releases/tag/v5.9.0-rc2
>>>>>>>
>>>>>>>
>>>>>>> Please download the product, test it, and vote using the following
>>>>>>> convention.
>>>>>>>
>>>>>>> [+] Stable - go ahead and release
>>>>>>>
>>>>>>> [-] Broken - do not release (explain why)
>>>>>>>
>>>>>>> Thanks,
>>>>>>>
>>>>>>> WSO2 Identity and Access Management Team
>>>>>>>
>>>>>>> *Piraveena Paralogarajah*
>>>>>>> Software Engineer | WSO2 Inc.
>>>>>>> *(m)* +94776099594 | *(e)* pirave...@wso2.com
>>>>>>>
>>>>>>> ___
>>>>>> Dev mailing list
>>>>>> d...@wso2.org
>>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Niluka Sripali Monnankulama
>>>>> Software Engineer - WSO2 Sri Lanka
>>>>>
>>>>> Mobile : +94 76 76 52843
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> d...@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>> *Mathuriga Thavarajah*
>>>> Software Engineer
>>>> WSO2 Inc. - http ://wso2.com
>>>>
>>>> Email : mathur...@wso2.com
>>>> Mobile  : +94778191300
>>>>
>>>>
>>>>
>>>> *[image: http://wso2.com/signature] <http://wso2.com/signature>*
>>>> ___
>>>> Dev mailing list
>>>> d...@wso2.org
>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>
>>>
>>
>> --
>> Wijith Bandara
>> Software Engineer | WSO2
>>
>> Email : wij...@wso2.com
>> Mobile : +94718970370
>> Web : http://wso2.com
>>
>> <http://wso2.com/signature>
>> ___
>> Dev mailing list
>> d...@wso2.org
>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>
>
>
> --
>
> Hasanthi Dissanayake | Associate Technical Lead | WSO2 Inc.
> (m) +94718407133 | (w) +94112145345  | Email: hasan...@wso2.com  | Blog:
> https://medium.com/@hasanthipurnimadissanayake
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>


-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] Multiple keys support in JWKS endpoint

[Sathya Bandara]

Hi Inthirakumaaran,

What about the case where the user sends a JWT signed with the old key,
along with JWT grant type to IS? Then don't we need to update the JWT
signature validation logic to obtain the keys for the respective JWTs based
on the 'kid' value?

Thanks,
Sathya

On Tue, Apr 23, 2019 at 11:31 AM Inthirakumaaran Tharmakulasingham <
inthirakumaa...@wso2.com> wrote:

> 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
>
> <http://wso2.com/signature>
>
>
>

-- 
Sathya Bandara
Senior Software Engineer
Blog: https://medium.com/@technospace
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] OAuth clients based on a trusted CA

[Sathya Bandara]

Hi,

A similar concept is defined in 'OAuth 2.0 Mutual TLS Client
Authentication' specification [1]. There it defines two distinct methods
for certificate based client authentication.

1. PKI Mutual TLS OAuth Client Authentication

Uses a subject distinguished name (DN) and validated certificate chain
to identify the client.

2. Self-Signed Certificate Mutual TLS OAuth Client Authentication
Support client authentication using self-signed certificates.  Client
registers needs to associate a self-signed X.509 certificate at the time of
registering. The client is successfully authenticated, if the subject
public key info of the certificate matches the subject public key info of
one of the certificates configured or registered for that client.


Currently in IS we support only self-signed certificate based
authentication [2].

In the first method, client needs to associate the CA certificate and need
to provide the DN of the signed certificate at the time of client
registration. During mutual TLS handshake, we only need to validate
client's CA certificate. The client is successfully authenticated if the
subject information in the certificate matches with the expected DN
configured or registered for that particular client.

[1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1
[2] "[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0
clients"

Thanks,
Sathya

On Tue, Aug 7, 2018 at 10:50 AM, Prabath Siriwardena 
wrote:

> I guess following scenario will be useful in a microservices deployment,
> when we need to secure service to service communication.
>
> Please find below the steps..
>
> 1. We create a service provider provider, and associate a CA's certificate
> with it.
> 2. Now we have multiple microservices, each with a signed certificate from
> the previous trusted CA.
> 3. Each of those microservice will be able to talk to the /token endpoint
> of IS (or STS), authenticate with mTLS and get a token. The token request
> also carries an audience value (or implied in scope).
> 4. IS treats, the thumbprint of the cert (preferably SVID, in a
> SPIFFE/Istio environment) as the client id, and the access token is issued
> against it (which can be a JWT as well).
> 5. This new access token/JWT can be used for service to service
> authentication, within the same domain or cross domain.
>
> This helps to onboard all the microservices, carrying a key pair (as their
> workload identity) to an OAuth environment.
>
> WDYT..?
>
> Thanks & Regards,
> Prabath
>
> Twitter : @prabath
> LinkedIn : http://www.linkedin.com/in/prabathsiriwardena
>
> Blog: http://blog.facilelogin.com
> Vlog: http://vlog.facilelogin.com
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [Dev] [VOTE] Release of WSO2 Identity Server 5.6.0 RC3

[Sathya Bandara]

Hi all,

I've tested following scenarios on the IS 5.6.0-RC3 pack.

User management (add/update/remove users).
User management in secondary userstores (Read-Write LDAP).
Consent Management in SAML SSO.
SAML to SAML federation.
Creating workflows definitions for primary userstore users.
Engaging/Disabling workflows on user-store operations.
Enable role based authorization using XACML for service providers.
Tenant creation/update/disabling.

No blocking issues are found.

[+] Stable - go ahead and release.

Thanks,
Sathya


On Tue, Jun 19, 2018 at 12:26 PM, Vihanga Liyanage  wrote:

> Hi all,
>
> I've tested following scenarios on the IS 5.6.0-RC3 pack with default
> database setup.
>
>- Enable user self-registration and self-register a new user.
>- Add multiple consent purposes with multiple PII categories.
>- Login to dashboard and see whether we can see the default consent
>and above added PII categories.
>- Confirm claims are getting filtered based on consents.
>- Configure a service provider with OpenID Connect and acquire access
>tokens via Authorization Code, Implicit, Client Credential and Password
>grant types.
>- Enable ID token encryption for the service provider and test the
>flow with decryption for all grant types.
>- Delete the self-signed up user, create another user with the exact
>same username, log in to the dashboard and see what are the consents
>shown.
>- Revoke consents of the user via the dashboard and try accessing the
>SP to verify the consents are asked again.
>- Delete the SP, login to the dashboard and see whether the consents
>are deleted for that SP.
>
> No blocking issues are found.
>
> [+] Stable - go ahead and release.
>
> Thanks,
> Vihanga.
>
> On Fri, Jun 15, 2018 at 6:29 PM Madawa Soysa  wrote:
>
>> Hi all,
>>
>> We are pleased to announce the third release candidate of WSO2 Identity
>> Server 5.6.0.
>>
>> This release fixes the following issues
>>
>>- 5.6.0-RC Fixes
>><https://github.com/wso2/product-is/milestone/40?closed=1>
>>- 5.6.0-Beta Fixes
>><https://github.com/wso2/product-is/milestone/39?closed=1>
>>- 5.6.0-Alpha2 Fixes
>><https://github.com/wso2/product-is/milestone/43?closed=1>
>>- 5.6.0-Alpha Fixes
>><https://github.com/wso2/product-is/milestone/38?closed=1>
>>- 5.6.0-M7 Fixes
>><https://github.com/wso2/product-is/milestone/37?closed=1>
>>- 5.6.0-M6 Fixes
>><https://github.com/wso2/product-is/milestone/36?closed=1>
>>- 5.6.0-M5 Fixes
>><https://github.com/wso2/product-is/milestone/35?closed=1>
>>- 5.6.0-M4 Fixes
>><https://github.com/wso2/product-is/milestone/34?closed=1>
>>- 5.6.0-M3 Fixes
>><https://github.com/wso2/product-is/milestone/33?closed=1>
>>- 5.6.0-M2 Fixes
>><https://github.com/wso2/product-is/milestone/31?closed=1>
>>- 5.6.0-M1 Fixes
>><https://github.com/wso2/product-is/milestone/30?closed=1>
>>
>> Source and distribution,
>> Runtime -  https://github.com/wso2/product-is/releases/tag/v5.6.0-rc3
>> Analytics - https://github.com/wso2/analytics-is/releases/v5.6.0-rc3
>>
>> Please download, test the product and vote.
>>
>> [+] Stable - go ahead and release
>> [-] Broken - do not release (explain why)
>>
>> Thanks,
>> WSO2 Identity and Access Management Team
>> --
>>
>> Madawa Soysa / Senior Software Engineer
>> mada...@wso2.com / +94714616050
>>
>> *WSO2 Inc.*
>> lean.enterprise.middleware
>>
>>   <https://wso2.com/signature>
>>
>>
>>
>>
>
> --
>
> Vihanga Liyanage
>
> Software Engineer | WS*O₂* Inc.
>
> M : +*94710124103* | http://wso2.com
>
> [image: http://wso2.com/signature] <http://wso2.com/signature>
>
> ___
> Dev mailing list
> d...@wso2.org
> http://wso2.org/cgi-bin/mailman/listinfo/dev
>
>


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] WSO2 IS/APIM : support Mutual TLS Profile for OAuth 2.0 ?

[Sathya Bandara]

Hi Youcef,

Currently this feature supports client authentication using self-signed
certificates. You can refer the official documentation at [1].

[1]
https://docs.wso2.com/pages/viewpage.action?spaceKey=IS550=Mutual+TLS+for+OAuth+Clients

Thanks,
Sathya

On Fri, May 4, 2018 at 1:50 PM, Youcef HILEM <youcef.hi...@laposte.fr>
wrote:

> Hi,
> Good news : I just found that it's implemented :
> [1] https://github.com/wso2/product-is/issues/2751
> [2]
> http://wso2-oxygen-tank.10903.n7.nabble.com/IS-5-5-0-TLS-
> Mutual-Authentication-for-OAuth-2-0-clients-td155448.html
> [3]
> https://medium.com/@technospace/mutual-tls-for-
> oauth-client-authentication-cdd595d4dcac
>
> I will see how to use it with APIM.
>
>
> Thanks
> Youcef HILEM
>
>
>
> --
> Sent from: http://wso2-oxygen-tank.10903.n7.nabble.com/WSO2-
> Architecture-f62919.html
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>



-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IS] Capability to add jwks_uri while configuring identity providers

[Sathya Bandara]

[6]
https://static.javadoc.io/com.nimbusds/nimbus-jose-jwt/5.4/com/nimbusds/jose/jwk/source/RemoteJWKSet.html


Thanks,
Sathya
-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0 Released!

[Sathya Bandara]

WSO2 Identity Server 5.5.0 Released!

The WSO2 Identity Server team is pleased to announce the release of WSO2
Identity Server version 5.5.0.

WSO2 Identity Server is an open source identity and access management
server. It supports a wide array of authentication protocols such as SAML
2.0 Web SSO, OAuth 2.0/1.0a, OpenID Connect, and WS-Federation Passive. It
supports role based authorization and fine grained authorization with XACML
2.0/3.0 while inbound/outbound provisioning is supported through SCIM and
SPML.

WSO2 Identity Server is developed on top of the revolutionary WSO2 Carbon
platform, an OSGi based framework that provides seamless modularity to your
SOA solution via componentization.


All the major features have been developed as pluggable Carbon components.

You can download this distribution from
https://wso2.com/identity-and-access-management/install

Online documentation is available at
http://docs.wso2.org/wiki/display/IS550/WSO2+Identity+Server+Documentation.
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 files as appropriate

4. If you need to start the OSGi console with the server, use the property
-DosgiConsole when starting the server.
New Features in this Release

WSO2 Identity Server version 5.5.0 is part of WSO2’s Spring 2018 Release

which includes new features and updates across all products, solutions, and
services, that together empower organizations to rapidly comply with GDPR
.

The following includes major GDPR related features provided in WSO2 IS 5.5.0


   -

   Privacy Tool Kit - Supports removing references to a deleted user's
   identity as and when required.
   -

   Personal Information Export Capability - End users can retrieve personal
   information stored in WSO2 Identity Server.
   -

   Request Object Support - Ability to send authentication request
   parameters in a self-contained JWT.
   -

   User Consent for Single-Sign-On - Provides users with choice and control
   over sharing their personal data.
   -

   User Consent for Self Sign Up - Capability to provide consent during
   user self registration.
   -

   Consent  Management API - Manage user consents for collecting and
   sharing user's personal information.
   -

   Consent Purposes Management - An interactive UI to manage consent
   purposes/PII categories.
   -

   Private Key JWT Client Authentication - Facilitating OAuth2 client
   authentication using a signed JWT.


This release includes functional improvements and fixes to the product. The
complete list of improvements and bug fixes available with the release can
be found at the following locations:


   -

   5.5.0-RC2 fixes
   

   -

   5.5.0-RC1 fixes
   

   -

   5.5.0-Beta fixes
   

   -

   5.5.0-Alpha3 fixes
   

   -

   5.5.0-Alpha2 fixes
   

   -

   5.5.0-Alpha fixes
   

   -

   5.5.0-M4 fixes
   

   -

   5.5.0-M3 fixes
   

   -

   5.5.0-M2 fixes
   

   -

   5.5.0-M1 fixes
   


Known Issues

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

IS Runtime 

IS Analytics 
How You Can ContributeMailing Lists

Join our mailing list and correspond with the developers directly.

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


User forum: StackOverflow 
Reporting Issues

We encourage you to report issues, documentation faults, and feature
requests regarding WSO2 Identity Server or in the Carbon base framework
through the public WSO2 Identity Server JIRA.
Support

We are committed to ensure your enterprise middleware deployment is
completely supported from evaluation to production through a WSO2
Subscription. Our unique approach ensures that all support leverages our
open development methodology and is provided by the very same engineers who
build the technology. For more 

Re: [Architecture] [Dev] [VOTE] Release WSO2 Identity Server 5.5.0 RC2

[Sathya Bandara]

   - 5.5.0-Alpha3 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha3>
>>>>>>- 5.5.0-Alpha2 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha2>
>>>>>>- 5.5.0-Alpha fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha>
>>>>>>- 5.5.0-M4 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M4>
>>>>>>- 5.5.0-M3 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M3>
>>>>>>- 5.5.0-M2 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M2>
>>>>>>- 5.5.0-M1 fixes
>>>>>>
>>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M1>
>>>>>>
>>>>>>
>>>>>> Source and distribution
>>>>>>
>>>>>> Runtime - https://github.com/wso2/product-is/releases/v5.5.0-rc2
>>>>>> Analytics - https://github.com/wso2/anal
>>>>>> ytics-is/releases/v5.5.0-rc2
>>>>>>
>>>>>>
>>>>>> Please download, test the product and vote.
>>>>>>
>>>>>> [+] Stable - go ahead and release
>>>>>> [-] Broken - do not release (explain why)
>>>>>>
>>>>>>
>>>>>> Thanks,
>>>>>> - WSO2 Identity and Access Management Team -
>>>>>>
>>>>>> --
>>>>>> Regards,
>>>>>>
>>>>>>
>>>>>> *Darshana Gunawardana*Technical Lead
>>>>>> WSO2 Inc.; http://wso2.com
>>>>>>
>>>>>> *E-mail: darsh...@wso2.com <darsh...@wso2.com>*
>>>>>> *Mobile: +94718566859 <+94%2071%20856%206859>*Lean . Enterprise .
>>>>>> Middleware
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>>
>>>>> Best Regards,
>>>>>
>>>>> Nuwandi Wickramasinghe
>>>>>
>>>>> Senior Software Engineer
>>>>>
>>>>> WSO2 Inc.
>>>>>
>>>>> Web : http://wso2.com
>>>>>
>>>>> Mobile : 0719214873 <071%20921%204873>
>>>>>
>>>>> ___
>>>>> Dev mailing list
>>>>> d...@wso2.org
>>>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>>>
>>>>>
>>>>
>>>>
>>>> --
>>>>
>>>>
>>>>
>>>> *Kind Regards,Nipuni Bhagya*
>>>>
>>>> *Software Engineering Intern*
>>>> *WSO2*
>>>>
>>>>
>>>>
>>>> *Mobile : +94 0779028904 <+94%2077%20767%201807>*
>>>>
>>>> ___
>>>> Architecture mailing list
>>>> Architecture@wso2.org
>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>>
>>>>
>>>
>>>
>>> --
>>> *Dinali Rosemin Dabarera*
>>> Software Engineer
>>> WSO2 Lanka (pvt) Ltd.
>>> Web: http://wso2.com/
>>> Email : gdrdabar...@gmail.com
>>> LinkedIn <https://lk.linkedin.com/in/dinalidabarera>
>>> Mobile: +94770198933 <077%20019%208933>
>>>
>>>
>>>
>>>
>>> <https://lk.linkedin.com/in/dinalidabarera>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> ___
>>> Dev mailing list
>>> d...@wso2.org
>>> http://wso2.org/cgi-bin/mailman/listinfo/dev
>>>
>>>
>>
>> Thanks,
>> --
>> Pushpalanka.
>> --
>> Pushpalanka Jayawardhana, B.Sc.Eng.(Hons).
>> Senior Software Engineer, WSO2 Lanka (pvt) Ltd;  wso2.com/
>> Mobile: +94779716248
>> Blog: pushpalankajaya.blogspot.com/ | LinkedIn: lk.linkedin.com/in/p
>> ushpalanka/ | Twitter: @pushpalanka
>>
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> Denuwanthi De Silva
> Senior Software Engineer;
> WSO2 Inc.; http://wso2.com,
> Email: denuwan...@wso2.com
> Blog: https://denuwanthi.wordpress.com/
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [VOTE] Release WSO2 Identity Server 5.5.0 RC1

[Sathya Bandara]

Hi all,

We are calling-off this vote as we have found an issue,

   - for user-mgt ui component in EI product
   - in Windows environment

Since we want to align same component versions among EI & IS, we will fix
this and update versions in IS as well. Additionally we will fix the issue
in README.txt along with this.
We will do a RC2 and call for a vote soon.

[1] https://github.com/wso2/product-ei/issues/2004

On Wed, Mar 14, 2018 at 6:29 PM, Nilasini Thirunavukkarasu <
nilas...@wso2.com> wrote:

> Hi,
>
> I have tested the following flows in mysql.
>
>- User management, role management (Primary + Secondary user store)
>- OIDC flow (password grant, authorization code)(Primary + Secondary
>user store)
>- consent management with SAML SSO for primary and secondary users.
>- SAML assertion encryption and response signing.
>
>
> I have tested the following flow with h2
>
>- federated scenario with two IS
>
> +1 to go ahead and release
>
>
> Thanks,
> Nila.
>
>
> On Wed, Mar 14, 2018 at 6:15 PM, Darshana Gunawardana <darsh...@wso2.com>
> wrote:
>
>> Hi Dilini,
>>
>> We will fix this, if we noted any blocker for RC1 release.. If not, let's
>> continue on the vote considering this is a known issue..
>>
>> Thanks,
>>
>> On Wed, Mar 14, 2018 at 6:05 PM, Dilini Gunatilake <dili...@wso2.com>
>> wrote:
>>
>>> Hi,
>>>
>>> The README .txt contains references to old documentation and few other
>>> issues which is reported in [1]. Better if we can fix those. WDUT?
>>>
>>> [1] https://github.com/wso2/product-is/issues/2945
>>>
>>> Regards,
>>> Dilini
>>>
>>>
>>>
>>> On Wed, Mar 14, 2018 at 5:23 PM, Farasath Ahamed <farasa...@wso2.com>
>>> wrote:
>>>
>>>>
>>>> Tested Below scenario on the IS 5.5.0-RC1 pack with MSSQL database
>>>>
>>>>- Create an OAuth app using Dynamic Client Registration endpoint
>>>>- Configured mandatory claims for the service provider
>>>>- Tested OIDC Implicit flow with user consent management enabled
>>>>- Verified that the user claims sent in the id_token are filtered
>>>>based on user consent.
>>>>
>>>> +1 to go ahead and release
>>>>
>>>>
>>>> On Wed, Mar 14, 2018 at 11:16 AM, Sathya Bandara <sat...@wso2.com>
>>>> wrote:
>>>>
>>>>> Hi all,
>>>>>
>>>>> We are pleased to announce the first release candidate of WSO2
>>>>> Identity Server 5.5.0.
>>>>>
>>>>> This is the first release candidate (RC) of the WSO2 Identity Server
>>>>> 5.5.0 release.
>>>>>
>>>>>
>>>>> This release fixes the following issues
>>>>>
>>>>>- 5.5.0-RC1 fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-RC1>
>>>>>- 5.5.0-Beta fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-beta>
>>>>>- 5.5.0-Alpha3 fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha3>
>>>>>- 5.5.0-Alpha2 fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha2>
>>>>>- 5.5.0-Alpha fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha>
>>>>>- 5.5.0-M4 fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M4>
>>>>>- 5.5.0-M3 fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M3>
>>>>>- 5.5.0-M2 fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M2>
>>>>>- 5.5.0-M1 fixes
>>>>>
>>>>> <https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M1>
>>>>>
>>>>>
>>>>> Source and distribution
>>>>>
>>>>> Runtime - https://github.com/wso2/produc
>>>>> t-is/releases/tag/v5.5.0-rc1
>>>>> Analytics - htt

[Architecture] [VOTE] Release WSO2 Identity Server 5.5.0 RC1

[Sathya Bandara]

Hi all,

We are pleased to announce the first release candidate of WSO2 Identity
Server 5.5.0.

This is the first release candidate (RC) of the WSO2 Identity Server 5.5.0
release.


This release fixes the following issues

   - 5.5.0-RC1 fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-RC1>
   - 5.5.0-Beta fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-beta>
   - 5.5.0-Alpha3 fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha3>
   - 5.5.0-Alpha2 fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha2>
   - 5.5.0-Alpha fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-alpha>
   - 5.5.0-M4 fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M4>
   - 5.5.0-M3 fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M3>
   - 5.5.0-M2 fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M2>
   - 5.5.0-M1 fixes
   
<https://github.com/wso2/product-is/issues?q=is%3Aclosed+milestone%3A5.5.0-M1>


Source and distribution

Runtime - https://github.com/wso2/product-is/releases/tag/v5.5.0-rc1
Analytics - https://github.com/wso2/analytics-is/releases/tag/v5.5.0-rc1


Please download, test the product and vote.

[+] Stable - go ahead and release
[-] Broken - do not release (explain why)


Thanks,
- WSO2 Identity and Access Management Team -

-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0-Beta Released!

[Sathya Bandara]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.5.0 Beta!
Download

You can download WSO2 Identity Server 5.5.0 Beta distributions from
following locations.

Identity Server:
https://github.com/wso2/product-is/releases/download/v5.5.0-beta/wso2is-5.5.0-beta


IS Analytics: https://github.com/wso2/analytics-is/release
s/download/v5.5.0-beta/wso2is-analytics-5.5.0-beta

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.



What's new in WSO2 Identity Server 5.5.0 Beta

   -

   Bug fixes


   



   -

   Improvements


   


A list of all the resolved issues shipped with this release can be found he
re

Online documentation is available at
https://docs.wso2.com/display/IS550/WSO2+Identity+Server+Documentation.

Known Issues

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

   -

   IS Runtime 
   -

   IS Analytics 



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 forum: StackOverflow


Reporting Issues

We encourage you to report issues, improvements, documentation faults, and
feature requests regarding WSO2 Identity Server through WSO2 Identity
Server GIT 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 ~
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0-Alpha3 Released!

[Sathya Bandara]

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

You can download WSO2 Identity Server 5.5.0 Alpha3 distributions from
following locations.


Identity Server: https://github.com/wso2/product-is/releases/download/
v5.5.0-alpha3//wso2is-5.5.0-alpha3
<https://github.com/wso2/product-is/releases/download/v5.5.0-alpha3/wso2is-5.5.0-alpha3.zip>

IS Analytics: https://github.com/wso2/analytics-is/releases/tag/v5.
5.0-alpha3/wso2is-analytics-5.5.0-alpha3
<https://github.com/wso2/analytics-is/releases/download/v5.5.0-alpha3/wso2is-analytics-5.5.0-alpha3.zip>
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.



What's new in WSO2 Identity Server 5.5.0 Alpha3

Following includes major features/improvements provided in WSO2 IS
5.5.0-Alpha3.


   -

   Tenancy support for PII controllers - Capability to configure PII
   controllers per tenant basis.
   -

   Consent Management in OIDC - Integrating User Consent Management into
   OpenID connect Authorization Code and Implicit flow.


A list of new features and bug fixes shipped with this release can be found
here <https://github.com/wso2/product-is/milestone/25?closed=1>

Online documentation is available at https://docs.wso2.com/display/
IS550/WSO2+Identity+Server+Documentation.


Known Issues

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

   -

   IS Runtime <https://github.com/wso2/product-is/issues>
   -

   IS Analytics <https://github.com/wso2/analytics-is/issues>



How You Can Contribute

Mailing Lists

Join our mailing list and correspond with the developers directly.

Developer list: d...@wso2.org | Subscribe | Mail Archive
<http://mail.wso2.org/mailarchive/dev/>

User forum: StackOverflow
<http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues

We encourage you to report issues, improvements, documentation faults, and
feature requests regarding WSO2 Identity Server through WSO2 Identity
Server GIT Issues <https://github.com/wso2/product-is/issues>.

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


~ The WSO2 Identity and Access Management Team ~


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0-Alpha2 Released!

[Sathya Bandara]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.5.0 Alpha2!
Download

You can download WSO2 Identity Server 5.5.0 Alpha2 distributions from
following locations.


Identity Server:
https://github.com/wso2/product-is/releases/download/v5.5.0-alpha2//wso2is-5.5.0-alpha2
<https://github.com/wso2/product-is/releases/download/v5.5.0-alpha2/wso2is-5.5.0-alpha2.zip>

IS Analytics: https://github.com/wso2/analytics-is/releases/tag/v5.
5.0-alpha2/wso2is-analytics-5.5.0-alpha2
<https://github.com/wso2/analytics-is/releases/download/v5.5.0-alpha2/wso2is-analytics-5.5.0-alpha2.zip>
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.



What's new in WSO2 Identity Server 5.5.0 Alpha2

Following includes major features/improvements provided in WSO2 IS
5.5.0-Alpha2



   -

   Tenancy Support for Self Sign Up Page
   <https://docs.wso2.com/display/IS550/Self+Sign+Up+and+Account+Confirmation>
   - Facility to view the self registration page honoring tenant
   configurations.
   -

   System Consent Management from user Dashboard
   
<https://docs.wso2.com/display/IS550/Using+the+End+User+Dashboard#UsingtheEndUserDashboard-Configuringconsentforservices>
   - Separate resident IDP consent in the dashboard gadget to manage consents.


   -

   Display names for user claims in consent SSO page
   <https://docs.wso2.com/display/IS550/Consent+Management+with+Single-Sign-On>
   - Ability to show display names of consent requested claims in consent
   SSO page.
   -

   Upload service provider public certificates
   
<https://docs.wso2.com/display/IS550/Adding+and+Configuring+a+Service+Provider>
   - Capability to register service provider specific public certificate via
   file upload.

A list of all the new features and bug fixes shipped with this release can
be found here <https://github.com/wso2/product-is/milestone/22?closed=1>

Online documentation is available at https://docs.wso2.com/display/
IS550/WSO2+Identity+Server+Documentation.


Known Issues

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

   -

   IS Runtime <https://github.com/wso2/product-is/issues>
   -

   IS Analytics <https://github.com/wso2/analytics-is/issues>



How You Can Contribute

Mailing Lists

Join our mailing list and correspond with the developers directly.

Developer list: d...@wso2.org | Subscribe | Mail Archive
<http://mail.wso2.org/mailarchive/dev/>

User forum: StackOverflow
<http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues

We encourage you to report issues, improvements, documentation faults, and
feature requests regarding WSO2 Identity Server through WSO2 Identity
Server GIT Issues <https://github.com/wso2/product-is/issues>.

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


~ The WSO2 Identity and Access Management Team ~


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

Hi all,

Please find below, the technical approaches discussed apart from the UX
level improvements mentioned above.

With the improvement in [1] we have the capability to upload multiple
truststores to the Identity Server from the management console. These
truststores will be added to the registry. With this capability we can
maintain a separate trustore per the feature (mutual TLS).

When uploading certificates for mutual TLS authentication, we can ask the
client to upload the certificate to this specific truststore from
management console. In order overcome the limitation of tomcat caching the
certificate store, we can add another tomcat connector which will override
the existing tomcat-connector. We can specifically apply this connector to
the requests directed to the oauth endpoints. And to this connector we can
specify a custom dynamic trust manager and use it to re-load the truststore
on every SSL session. Basically we should have a registry based dynamic
trust manager to reload the certificates from the feature-specific
truststore.

We also have the option to generalize the dynamic trust manager provided in
[1] which was originally implemented for the components within IS that are
initiating SSL connections with external clients.

Since with the above approach we will have truststores per feature, we can
avoid the conflicts with the existing authenticators. e.g
MutualSSLAuthenticator, X509Authenticator. However we will need to manage a
reference of truststore against the feature id in a map.


[1] https://github.com/wso2/carbon-identity/pull/1511

Thanks,
Sathya.

On Wed, Feb 21, 2018 at 1:02 PM, Johann Nallathamby <joh...@wso2.com> wrote:

> Had an offline discussion with Sathya. Following are the UX level features
> we need at high level. Sathya will reply with the technical approaches we
> discussed. We also discussed some possible solutions for the technical
> problems Sathya has raised above, which Sathya will explain.
>
> Basically we should be able to support both options  above mentioned by
> Sathya.
>
> *Option 1 - PKI Mutual TLS OAuth Client Authentication Method*
>
> This is important for large organizations with centralized governance
> where adding individual certs for service providers won't scale. Such
> organizations generally have an internal CA who issues certificates to all
> the clients. Therefore having the root CA in our trust store should be
> enough.
>
> However we need to validate the exact client of the request. We discussed
> following two options.
> 1. Organization can decide that all the certificates they are going to
> issue for this purpose will have the client_id as the CN. This will
> externally guarantee that the certificates sent by the clients are verified
> by a trusted 3rd party.
> 2. Register the expected CN/DN of the client when registering the OAuth2
> client. If we are able to retrieve the client by the registered CN/DN, then
> we don't even need to send the client_id as an additional parameter.
> Otherwise we need to send the client_id parameter separately. Since the
> spec is not very concrete here both options should be fine.
>
> *Option 2 - Self-Signed Certificate Mutual TLS OAuth Client Authentication
> Method Mutual*
>
> Import the certificate for each service provider. Generally considered
> less scalable. But good to support for smaller organizations with less
> centralized governance. To identify the exact client, both options
> suggested above will work, but doesn't make a significant difference
> because we are anyway storing the entire certificate per service provider.
> As mentioned above for option 2, either we can lookup the client by CN/DN
> in the uploaded cert, or send the client_id as an additional parameter.
>
> CRL/OCSP can be easily supported now, because we have a service to do
> this. We just need to get the registered OSGi service and validate the
> certs. Shouldn't take anything more than a day to integrate this code
> ideally.
>
> Regards,
> Johann.
>
> On Wed, Feb 21, 2018 at 7:54 AM, Hasintha Indrajee <hasin...@wso2.com>
> wrote:
>
>> For option 1, it seems validating the DN of the received certificate
>> against the one which we have stored for the service provider is enough.
>> For option 2 we can validate the public key of the certificate which is
>> received, against the public key of the certificate we store for the SP.
>> AFAIU this should be fine. We don't need to worry about validating
>> certificate since it happens in the container level AFAIK. But we may need
>> to call to CRL and OCSP endpoints and validate the certificate. Again this
>> is an improvement and should be optional.
>>
>> On Wed, Feb 21, 2018 at 11:25 AM, Johann Nallathamby <joh...@wso2.com>
>> wrote:
>>
&g

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

Hi all,

I'm currently working on integrating the changes in [1] to provide the
capability to upload client certificates to truststore during run time
without restart.

As per the implementation in [1] the default trust manager will be replaced
with a custom trust manager which will reload the client-truststore.jks
whenever there is a SSL validation failure. However in the case where there
are many SSL failures it will reload the JKS file for each and every
validation failure which will slow the server.

With the above mentioned concern, should I proceed with this integration?
Appreciate your thoughts.

[1] https://github.com/wso2/carbon-identity/pull/1511

Thanks,
Sathya


On Mon, Feb 19, 2018 at 3:57 PM, Sathya Bandara <sat...@wso2.com> wrote:

> Hi all,
>
> The basic implementation for this feature is completed and we held an
> initial code review for this. Review notes can be found in [1]. We were
> able to identify the following key limitations when including this feature
> in the product.
>
>
>1. In order to use the client certificate in the authentication
>request, the certificate needs to be imported to our truststore as a
>pre-requisite. As a result we will have to ask to restart the server. Even
>if we add the certificate via Management console it will not be applied
>unless the server is restarted with the current implementation. In order to
>overcome this requirement , we need to improve our existing implementation
>to add certificates at runtime without restarting the server. Part of this
>improvement is already provided in [1] which provides the following
>capabilities.
>
>- Alter UI to view the default trust store.
>   - Alter keystore management service to support the addition of
>   trust stores.
>   - Create a X509TrustManager implementation that dynamically reloads
>   any changes made to the trust store. Anyone using this
>   "DynamicX509TrustManager" with SSLContext will not require to restart 
> the
>   server for changes to client trust store to take effect.
>
>   2. Since in the current approach of mutual authentication using
>TLS, we need to add the client certificate to the cient-trustore.jks in
>order handle mutual TLS at at web container level (tomcat), during TLS
>handshake. In this scenario all the client certificates will be accessible
>globally since we cannot override the trustore at SP level. Since our admin
>services are protected by the Mutual-SSL-authenticator, clients can
>successfully authenticate from mutual SSL authenticator using their
>certificates and consume admin services. As a work-around we can
>specifically ask to disable the mutual-SSL-authenticator if the requirement
>is to use mutual TLS for client authentication. However, the proper
>solution would be to find an approach for the web container to dynamically
>identify the client specific certificates during runtime.
>
>3. Configuring the Tomcat connector for TLS Using the Server Keystore
>requires to restart Tomcat whenever we change the contents of the keystore
>since they are cached at launch and are not re-examined until the server
>process is bounced. We need to investigate an approach to avoid server
>restart and dynamically load the keystore content. One possible solution
>would be to implement a custom trustManagerClass and then use it to load
>the KeyStore on every ssl-session [3].
>
> In order to overcome the above limitations, supplementary
> features/capabilities are required. Please find the following task break
> down in order to address these limitations.
>
> Task 1 - Capability to upload the client certificate to the trustore.jks
> from UI and dynamically apply the certificate changes during runtime.
>
>- Sub-Task 1 - Merge the changes in [2] to carbon-identity-framework
>master branch and test the functionality.
>
>
>- Sub-Task 2 - Implement a mechanism to sync truststore changes in
>cluster.
>
>
>- Sub-Task 3 - Investigate an approach to avoid tomcat restart and
>dynamically load the keystore content for the connector.
>
>
> Task 2 - Address the conflicts with existing authenticators (e.g.
> MutualSSLAuthenticator/X509 Authenticator) when engaging the TLS Mutual
> Authenticator.
>
>- Sub-Task 1: Improve the existing MutualSSLAuthenticator to add a
>secondary factor of validation.
>
>
>- Sub-Task 2: Improve the existing X509 Authenticator to add a
>secondary factor of validation.
>
>
> Appreciate your feedback and suggestions.
>
> [1] Invitation: [Review] User Story - Mutual TLS Authentication for Oauth
> 2.0 clients @ Mon Feb 12, 2018 2pm - 3pm (IS

Re: [Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

Hi all,

The basic implementation for this feature is completed and we held an
initial code review for this. Review notes can be found in [1]. We were
able to identify the following key limitations when including this feature
in the product.


   1. In order to use the client certificate in the authentication request,
   the certificate needs to be imported to our truststore as a pre-requisite.
   As a result we will have to ask to restart the server. Even if we add the
   certificate via Management console it will not be applied unless the server
   is restarted with the current implementation. In order to overcome this
   requirement , we need to improve our existing implementation to add
   certificates at runtime without restarting the server. Part of this
   improvement is already provided in [1] which provides the following
   capabilities.

   - Alter UI to view the default trust store.
  - Alter keystore management service to support the addition of trust
  stores.
  - Create a X509TrustManager implementation that dynamically reloads
  any changes made to the trust store. Anyone using this
  "DynamicX509TrustManager" with SSLContext will not require to restart the
  server for changes to client trust store to take effect.

  2. Since in the current approach of mutual authentication using TLS,
   we need to add the client certificate to the cient-trustore.jks in order
   handle mutual TLS at at web container level (tomcat), during TLS handshake.
   In this scenario all the client certificates will be accessible globally
   since we cannot override the trustore at SP level. Since our admin services
   are protected by the Mutual-SSL-authenticator, clients can successfully
   authenticate from mutual SSL authenticator using their certificates and
   consume admin services. As a work-around we can specifically ask to disable
   the mutual-SSL-authenticator if the requirement is to use mutual TLS for
   client authentication. However, the proper solution would be to find an
   approach for the web container to dynamically identify the client specific
   certificates during runtime.

   3. Configuring the Tomcat connector for TLS Using the Server Keystore
   requires to restart Tomcat whenever we change the contents of the keystore
   since they are cached at launch and are not re-examined until the server
   process is bounced. We need to investigate an approach to avoid server
   restart and dynamically load the keystore content. One possible solution
   would be to implement a custom trustManagerClass and then use it to load
   the KeyStore on every ssl-session [3].

In order to overcome the above limitations, supplementary
features/capabilities are required. Please find the following task break
down in order to address these limitations.

Task 1 - Capability to upload the client certificate to the trustore.jks
from UI and dynamically apply the certificate changes during runtime.

   - Sub-Task 1 - Merge the changes in [2] to carbon-identity-framework
   master branch and test the functionality.


   - Sub-Task 2 - Implement a mechanism to sync truststore changes in
   cluster.


   - Sub-Task 3 - Investigate an approach to avoid tomcat restart and
   dynamically load the keystore content for the connector.


Task 2 - Address the conflicts with existing authenticators (e.g.
MutualSSLAuthenticator/X509 Authenticator) when engaging the TLS Mutual
Authenticator.

   - Sub-Task 1: Improve the existing MutualSSLAuthenticator to add a
   secondary factor of validation.


   - Sub-Task 2: Improve the existing X509 Authenticator to add a secondary
   factor of validation.


Appreciate your feedback and suggestions.

[1] Invitation: [Review] User Story - Mutual TLS Authentication for Oauth
2.0 clients @ Mon Feb 12, 2018 2pm - 3pm (IST) (WSO2 Engineering Group)
[2] https://github.com/wso2/carbon-identity/pull/1511
[3]
https://stackoverflow.com/questions/5816239/how-do-i-force-tomcat-to-reload-trusted-certificates

Thanks,
Sathya

On Fri, Feb 9, 2018 at 12:34 PM, Hasintha Indrajee <hasin...@wso2.com>
wrote:

> Can we also validate these certificates using CRLs and OSCP endpoints
> provided in certificate ?. Also better if this validation can be made
> optional and can be governed through a configuration. This configuration
> will just be a handler property.
>
> *@Indunil : *Do we have this feature bundled in product (Certificate
> validation using OSCP and CRL) ?
>
> On Fri, Feb 9, 2018 at 12:20 PM, Sathya Bandara <sat...@wso2.com> wrote:
>
>> Hi all,
>>
>> Mutual TLS is a widely used, secure, authentication technique in
>> enterprise environments to ensure the authenticity of the clients to server
>> and vice versa. It facilitates authentication via certificates followed by
>> the establishment of an encrypted channel between the parties.
>>
>> The OAuth 2.0 Authorization Framework a

[Architecture] WSO2 Identity Server 5.5.0-Alpha Released!

[Sathya Bandara]

WSO2 Identity and Access Management team is pleased to announce the release
of Identity Server 5.5.0 Alpha!
Download

You can download WSO2 Identity Server 5.5.0 Alpha distributions from
following locations.

Identity Server:
https://github.com/wso2/product-is/releases/download/v5.5.0-alpha
<https://github.com/wso2/product-is/releases/download/v5.5.0-alpha/wso2is-5.5.0-alpha.zip>

IS Analytics: https://github.com/wso2/analytics-is/releases/tag/v5.5.0-alpha
<https://github.com/wso2/analytics-is/releases/download/v5.5.0-alpha/wso2is-5.5.0-alpha.zip>
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.



What's new in WSO2 Identity Server 5.5.0 Alpha

WSO2 Identity Server 5.5.0-Alpha is designed based on privacy best
practices and adhering to GDPR. Your GDPR compliance in IAM and API
security space can be fulfilled with WSO2 IS. Following includes major GDPR
related features provided in WSO2 IS 5.5.0-Alpha.



   -

   Privacy Tool Kit
   
<https://docs.wso2.com/display/IS550/Removing+References+to+Deleted+User+Identities>
-
   Supports removing references to a deleted user's identity as and when
   required.
   
<https://docs.wso2.com/display/IS550/Using+the+End+User+Dashboard#UsingtheEndUserDashboard-Exportingpersonalinformation>
   -

   Personal Information Export Capability
   
<https://docs.wso2.com/display/IS550/Using+the+End+User+Dashboard#UsingtheEndUserDashboard-Exportingpersonalinformation>
   - End users can retrieve  personal information stored in WSO2 Identity
   Server.
   <https://docs.wso2.com/display/IS550/Consent+Management+with+Single-Sign-On>
   -

   User Consent for Single-Sign-On
   <https://docs.wso2.com/display/IS550/Consent+Management+with+Single-Sign-On>
   - Provides users with choice and control over sharing their personal data.
   <https://docs.wso2.com/display/IS550/Consent+Management+for+Self+Sign+Up>
   -

   User Consent for Self Sign Up
   <https://docs.wso2.com/display/IS550/Consent+Management+for+Self+Sign+Up>
   - Capability to provide consent when a user self registers to WSO2 Identity
   Server. <https://docs.wso2.com/display/IS550/Managing+Consent+Purposes>
   -

   Consent Purposes Management
   <https://docs.wso2.com/display/IS550/Managing+Consent+Purposes> -  An
   interactive UI to manage consent purposes/PII categories.
   
<https://docs.wso2.com/display/IS550/Private+Key+JWT+Client+Authentication+for+OIDC>
   -

   Private Key JWT Client Authentication
   
<https://docs.wso2.com/display/IS550/Private+Key+JWT+Client+Authentication+for+OIDC>
   - Facilitating client authentication using a signed JWT.
   -

   Encrypted ID token for OIDC Flow
   
<https://docs.wso2.com/display/IS550/Testing+OIDC+Encrypted+ID+Token+with+IS+5.5.0>
   - Capability to encrypt ID tokens with a registered public key.

A list of all the new features and bug fixes shipped with this release can
be found here <https://github.com/wso2/product-is/milestone/20?closed=1>

Online documentation is available at
https://docs.wso2.com/display/IS550/WSO2+Identity+Server+Documentation.


Known Issues

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

   -

   IS Runtime <https://github.com/wso2/product-is/issues>
   -

   IS Analytics <https://github.com/wso2/analytics-is/issues>



How You Can Contribute

Mailing Lists

Join our mailing list and correspond with the developers directly.

Developer list: d...@wso2.org | Subscribe | Mail Archive
<http://mail.wso2.org/mailarchive/dev/>

User forum: StackOverflow
<http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues

We encourage you to report issues, improvements, documentation faults, and
feature requests regarding WSO2 Identity Server through WSO2 Identity
Server GIT Issues <https://github.com/wso2/product-is/issues>.

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


~ The WSO2 Identity and Access Management Team ~


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IS 5.5.0] TLS Mutual Authentication for OAuth 2.0 clients

[Sathya Bandara]

Hi all,

Mutual TLS is a widely used, secure, authentication technique in enterprise
environments to ensure the authenticity of the clients to server and vice
versa. It facilitates authentication via certificates followed by the
establishment of an encrypted channel between the parties.

The OAuth 2.0 Authorization Framework allows the use of additional client
authentication mechanisms. One such is the mechanism of client
authentication utilizing mutual TLS certificate-based authentication [1].
We can add this support for WSO2 Identity Server by providing an additional
OAuth client authenticator. In order to utilize TLS for OAuth client
authentication, the TLS connection between the client and the authorization
server must have been established with mutual X.509 certificate
authentication (i.e. the Client Certificate and Certificate Verify messages
are sent during the TLS Handshake).


The specification defines two ways of binding a certificate to a client as
two distinct client authentication methods [2].
1. PKI Mutual TLS OAuth Client Authentication Method

Uses a subject distinguished name (DN) and validated certificate chain
to identify the client. The client is successfully authenticated if
the subject information in the certificate matches the expected DN
configured or registered for that
particular client.

2. Self-Signed Certificate Mutual TLS OAuth Client Authentication Method
Mutual

support client authentication using self-signed certificates.  As
pre-requisite, the client registers an X.509 certificate or a trusted
source for its X.509 certificates (such as the "jwks_uri"). The client is
successfully authenticated, if the subject public key info of the
certificate matches the subject public key info of one of the certificates
configured or registered for that particular client.

In both approaches, TLS is utilized to validate the client's possession of
the private key corresponding to the public key presented within the
certificate in the respective TLS handshake during authentication.

We will follow the approach #2 since it prevents the necessity to validate
the certificate chain in contrast to the PKI method.


Also since the client cert authentication happens as part of the mutual TLS
handshake, it will happen at the web container level. Hence if the
authentication is successful, client's public certificate will be available
as a request attribute at the CXF servlet. Hence the Mutual TLS Client
Authenticator can be engaged by inferring the existence of the client cert
as a request attribute.

As we currently have the capability to upload Service Provider specific
public certificates, clients can register their public certificates during
service provider configuration. Within the authenticate method of the
MutualTLSClientAuthenticator, we can compare the registered certificate's
public key against the public key of the certificate presented in the TLS
handshake. If these two matches we can successfully authenticate the
client.

For all requests to the authorization server utilizing mutual TLS client
authentication, the client MUST include the "client_id" parameter as
described in OAuth 2.0 specification [3]. With the "client_id" parameter we
can easily obtain the client's registered certificate for authenticating
the client.

Highly appreciate your thoughts and suggestions.

[1] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07
[2] https://tools.ietf.org/html/draft-ietf-oauth-mtls-07#section-2.1
[3] https://tools.ietf.org/html/rfc6749#section-2.2

Thanks,
Sathya

-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0-M4 Released!

[Sathya Bandara]

*WSO2 Identity and Access Management team is pleased to announce the
release of Identity Server 5.5.0 M4!DownloadYou can download WSO2 Identity
Server 5.5.0 M4 from here
<https://github.com/wso2/product-is/releases/download/v5.5.0-m4/wso2is-5.5.0-m4.zip>.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.5.0 M4*


   -

   Consent Management API
   <https://docs.wso2.com/display/IS550/Consent+Management+Using+REST+APIs> to
   manage user consents for collecting and sharing user's personal information
   .
   -

   Request Object Support for OIDC
   
<https://docs.wso2.com/display/IS550/Request+Object+Support+for+WSO2+Identity+Server>
   providing ability to send authentication request parameters in a
   self-contained JWT instead of plain request parameters complying with GDPR
   and PSD2 standards.
   -

   Store service provider cert in DB instead of the keystore
   
<https://docs.wso2.com/display/IS550/Adding+and+Configuring+a+Service+Provider>
   facilitating the upload of Service Provider specific public certificates.
   -

   UI Based JWT configuration support
   
<https://docs.wso2.com/display/IS550/Configuring+OAuth2-OpenID+Connect+Single-Sign-On>
   for configuring service provider specific JWT audiences via SP Oauth config
   UI.





*A list of all the new features and bug fixes shipped with this release can
be found here <https://github.com/wso2/product-is/milestone/18?closed=1>
<https://github.com/wso2/product-is/milestone/15?closed=1>Online
documentation is available at
https://docs.wso2.com/display/IS550/WSO2+Identity+Server+Documentation
<https://docs.wso2.com/display/IS550/WSO2+Identity+Server+Documentation>.*
















*Known IssuesAll the open issues pertaining to WSO2 Identity Server are
reported at the following location: - IS Runtime
<https://github.com/wso2/product-is/issues>How You Can ContributeMailing
ListsJoin our mailing list and correspond with the developers directly.
Developer list: d...@wso2.org <d...@wso2.org> | Subscribe | Mail Archive
<http://mail.wso2.org/mailarchive/dev/> User forum: StackOverflow
<http://stackoverflow.com/questions/tagged/wso2is>Reporting IssuesWe
encourage you to report issues, improvements, documentation faults, and
feature requests regarding WSO2 Identity Server through WSO2 Identity
Server GIT Issues <https://github.com/wso2/product-is/issues>.For more
information about WSO2 Identity Server, please see
https://wso2.com/identity-and-access-management
<https://wso2.com/identity-and-access-management> or visit the WSO2 Oxygen
Tank <http://wso2.com/library/> developer portal for additional resources.~
The WSO2 Identity and Access Management Team ~*
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [GDPR-Compliance] Log Processing Tool

[Sathya Bandara]

Hi all,

For the purpose of making the WSO2 products GDPR compliance, we need to
make sure that all the instances of a username is removed from the system
upon the request of an end user. This may include database tables, Log
files, registry, analytics etc. In order to address the respective area
related to Log files I have implemented a custom tool to replace all the
occurrences of a username in the log files to support this compliance [1].
The system administrator can run this tool with the required inputs (e.g.
username, password, tenant domain and log file directory path etc) and the
tool will process all the log files and replace all the occurrences of the
username with a pseudonym.

The log processing tool works with a regex-pattern match approach where all
the identifiable patterns of username occurrences can be configured from an
external configuration file. Sample pattern configuration for a possible
username occurrence is as follows.


(.)*${userstoreDomain}(/{0}|/{1})${username}@
${tenantDomain}(.)*
${username}


All the log files available in the configured log file directory path will
be processed line by line and will be compared against all the configured
patterns in the pattern configuration file. The detectPattern will detect
the lines where the configured pattern matches and all the occurrences of
the replacePattern in that specific line will be replaced with a pseudonym
for the actual name. The replaced filenames and corresponding line numbers
will be included in a report in PDF format for later references.

As for the initial stage of the GDPR compliance log processing tool only
the exactly identified(where full qualified name of user is included) logs
will be replaced. Logs where only the username is present, i.e. without
tenant domain or userstore domain, is not replaced. These possible matches
will be included in the generated report with the corresponding line
numbers.

[1]
https://github.com/JKAUSHALYA/gdpr-compliance-tool/tree/master/components/org.wso2.carbon.privacy.forgetme.logs

Thanks,
Sathya
-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0-M3 Released!

[Sathya Bandara]

The WSO2 Identity and Access Management team is pleased to announce the
release of WSO2 Identity Server 5.5.0 M3
What's new in WSO2 Identity Server 5.5.0 M3

New Features & Bug Fixes: A list of new features and bug fixes shipped with
this release can be found here
<https://github.com/wso2/product-is/milestone/17?closed=1>
Download

You can download WSO2 Identity Server 5.5.0 M3 from here
<https://github.com/wso2/product-is/releases/download/v5.5.0-m3/wso2is-5.5.0-m3.zip>
.
Contribute to WSO2 Identity ServerMailing 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
   <http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server GIT
Issues <https://github.com/wso2/product-is/issues>.


~ The WSO2 Identity and Access Management Team ~


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0-M2 Released!

[Sathya Bandara]

The WSO2 Identity and Access Management team is pleased to announce the
release of WSO2 Identity Server 5.5.0 M2
What's new in WSO2 Identity Server 5.5.0 M2

New Features & Bug Fixes: A list of new features and bug fixes shipped with
this release can be found here
<https://github.com/wso2/product-is/milestone/15?closed=1>
Download

You can download WSO2 Identity Server 5.5.0 M2 from here
<https://github.com/wso2/product-is/releases/download/v5.5.0-m2/wso2is-5.5.0-m2.zip>
.
Contribute to WSO2 Identity ServerMailing 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
   <http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server GIT
Issues <https://github.com/wso2/product-is/issues>.


~ The WSO2 Identity and Access Management Team ~


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0-M1 Released!

[Sathya Bandara]

The WSO2 Identity and Access Management team is pleased to announce the
release of WSO2 Identity Server 5.5.0 M1
What's new in WSO2 Identity Server 5.5.0 M1

New Features & Bug Fixes: A list of new features and bug fixes shipped with
this release can be found here
<https://github.com/wso2/product-is/milestone/14?closed=1>
Download

You can download WSO2 Identity Server 5.5.0 M1 from here
<https://github.com/wso2/product-is/releases/download/v5.5.0-m1/wso2is-5.5.0-m1.zip>
.
Contribute to WSO2 Identity ServerMailing 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
   <http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server GIT
Issues <https://github.com/wso2/product-is/issues>.


~ The WSO2 Identity and Access Management Team ~


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] [IS 5.5.0] Conditional steps based on HTTP context

[Sathya Bandara]

Hi,

Thanks for the suggestion. I have modified the existing
DefaultRequestCoordinator and removed ConditionalRequestCoordinator since
there are no functional level changes in DefaultRequestCoordinator.

Following is a sample script to enforce conditional authentication based on
the HTTP context.


function(context) {
executeStep({
id: '1',
on: {
success: function (context) {

if (context.request.cookies.testcookie) {
log.info("--- cookie testcookie found in
request.");
log.info("--- cookie testcookie.value: " +
context.request.cookies.testcookie.value);
log.info("--- cookie testcookie.domain: " +
context.request.cookies.testcookie.domain);
log.info("--- cookie testcookie.max-age: "
+ context.request.cookies.testcookie["max-age"]);
log.info("--- cookie testcookie.path: " +
context.request.cookies.testcookie.path);
log.info("--- cookie testcookie.secure: " +
context.request.cookies.testcookie.secure);
log.info("--- cookie testcookie.version: "
+ context.request.cookies.testcookie.version);
log.info("--- cookie testcookie.httpOnly: "
+ context.request.cookies.testcookie.httpOnly);
} else {
executeStep({
id: '2',
on: {
success: function (context)
{
log.info("--- setting cookie :
testcookie");

context.response.headers["Set-Cookie"] = "testcookie=1FD36B269C61;
Path=/; Secure; HttpOnly; Expires=Wed, 21 Jan 2018 07:28:00 GMT"
}
}
});
}
}
}
});
}


In the above script, we define a cookie called *testcookie*. At the initial
authentication stage, the user has to go through both step 1 and step 2. If
authentication is successful, we will set a cookie (testcookie) in the
user's browser. At the next login session, if this cookie is found in the
authentication request, user will be authenticated from the first step
itself and the second authentication step will get skipped.

Thanks,
Sathya

On Wed, Jan 17, 2018 at 6:56 PM, Ruwan Abeykoon <ruw...@wso2.com> wrote:

> Hi Sathya,
>
> We can enhance the DefaultRequestCoordinator itself, rather than
> extending and creating new coordinator, as there is no functional change
> done by adding the "request" and "response" to authentication context.
>
> Cheers,
> Ruwan
>
> On Wed, Jan 17, 2018 at 10:40 AM, Sathya Bandara <sat...@wso2.com> wrote:
>
>> Hi all,
>>
>> We are currently working on improving the conditional authentication
>> support using JavaScript feature [1] to be able to handle authentication
>> conditions based on HTTP context.
>>
>> Following is the approach taken to achieve this requirement.
>>
>> In order to store the HTTP request and response I have modified the
>> default AuthenticationContext class to have additional state variables for
>> the authentication request and response(current request and response).
>> These variables are declared as transient such that they will not be used
>> for the object state at serialization. Furthermore, an additional variable
>> will be used to keep a reference to the initial authentication request
>> (initialRequest). When the second request comes, we will only update the
>> current request and response variables.
>>
>> The DefaultRequestCoordinator will be replaced with
>> ConditionalRequestCoordinator. In ConditionalRequestCordinator, inside
>> initializeFlow() method which gets called for the initial authentication
>> request, we instantiate an AuthenticationContext object. To this object, I
>> will set the current request, current response and initial request which is
>> the same as current request for the initial case. From the second request
>> for the ConditionalRequestCoordinator, only the current request and
>> response will be updated.
>>
>> In addition to the changes in the authentication framework, I have
>> implemented JavaScript wrapper classes for the HttpServletRequest and
>> HttpServletResponse Java classes in order to provide access to the
>> request/response state variables within JavaScript. Following are some
>> examples.
>>
>> *Request headers (context.request.headers)*
>>
>> context.request.headers.Authorization - this will give the value of th

[Architecture] [IS 5.5.0] Conditional steps based on HTTP context

[Sathya Bandara]

Hi all,

We are currently working on improving the conditional authentication
support using JavaScript feature [1] to be able to handle authentication
conditions based on HTTP context.

Following is the approach taken to achieve this requirement.

In order to store the HTTP request and response I have modified the default
AuthenticationContext class to have additional state variables for the
authentication request and response(current request and response). These
variables are declared as transient such that they will not be used for the
object state at serialization. Furthermore, an additional variable will be
used to keep a reference to the initial authentication request
(initialRequest). When the second request comes, we will only update the
current request and response variables.

The DefaultRequestCoordinator will be replaced with
ConditionalRequestCoordinator. In ConditionalRequestCordinator, inside
initializeFlow() method which gets called for the initial authentication
request, we instantiate an AuthenticationContext object. To this object, I
will set the current request, current response and initial request which is
the same as current request for the initial case. From the second request
for the ConditionalRequestCoordinator, only the current request and
response will be updated.

In addition to the changes in the authentication framework, I have
implemented JavaScript wrapper classes for the HttpServletRequest and
HttpServletResponse Java classes in order to provide access to the
request/response state variables within JavaScript. Following are some
examples.

*Request headers (context.request.headers)*

context.request.headers.Authorization - this will give the value of the
Authorization header.

*Request parameters (context.request.params)*

context.request.params.redirect_uri - this will give the value of the
request parameter redirect_uri

*Cookies in request (context.request.cookies)*

context.cookies.commonAuthId - this will create a JavaScript wrapper for
the Cookie Java Class. We can access individual cookie attributes using
this wrapper as follows.

context.request.cookies.commonAuthId.domain
context.request.cookies.commonAuthId.value

In request, we can only query existing attributes (headers and request
parameters). cannot add or modify existing values.

Similar approach was used for the HttpServletResponse class as well.
However in HttpServletResponse, we have the capability to add new headers
to the response.

*Adding headers to the response*

In order to wrap the setHeader() in JavaScript, I used the following
implementation.

public class JsHeaders extends AbstractJSObject {

private Map wrapped;
private HttpServletResponse response;

public JsHeaders(Map wrapped, HttpServletResponse response) {

this.wrapped = wrapped;
this.response = response;
}

@Override
public void setMember(String name, Object value) {

if (wrapped == null) {
super.setMember(name, value);
} else {
wrapped.put(name, value);
response.setHeader(name, (String) value); //replaces the value
if the name exists.
}
}
}

Here, I keep the existing headers in a map. Whenever
context.response.headers is called , an instance of the JsHeaders wrapper
is returned which contains the header map and a reference to the response.
Once a new header is added as in example context.response.headers.Authorization
= "sample_value", the setMember() function is called. It will add the
header (header name and value) to the referenced response.

e.g. context.response.headers["Content-Type"] = 'application/json'


*Adding cookies to the response *

Similarly, when adding a new cookie to the response, we will add a new
header to the response with the header name 'set-cookie'. This is similar
to the approach used in nodejs [2].

response.headers["set-cookie"] or response.headers.set-cookie can be used.

An example would be as follows.

response.headers.["Set-Cookie"] = ['crsftoken=xssometokenx',
'language=javascript']

Highly appreciate your thoughts and suggestions.

[1] [Architecture] Conditional Authentication Support on WSO2 Identity
Server
[2] https://nodejs.org/api/http.html#http_response_setheader_name_value
<https://nodejs.org/docs/v0.4.0/api/http.html#response.setHeader>

Thanks,
Sathya

-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] WSO2 Identity Server 5.5.0 is ready for the release process

[Sathya Bandara]

The WSO2 Identity and Access Management team is pleased to announce that
WSO2 Identity Server 5.5.0 branch is ready to be released. We have
performed a dry release to verify and confirm that the release process for WSO2
Identity Serve 5.5.0-M1 is now in a ready state.
You can build the distribution from the source tag, following the steps
given below.

*Building from the source*

   1. Install Java8 or above
   2. Install Apache Maven 3.x.x(https://maven.apache.org/download.cgi#)
   3. Get the source,
  - You can directly download the source from
  https://github.com/wso2/product-is/tree/5.5.x
   4. Run one of the below maven commands from product-is directory,
  - *mvn** clean install* (To build the binary and source distributions
  with the tests)
  - *mvn** clean install -Dmaven.test.skip=true* (To build the binary
  and source distributions, without running any of the
unit/integration tests)
   5. You can find the binary distribution in
product-is/modules/distribution/target
   directory.

What's new in WSO2 Identity Server 5.5.0 (As Of 2018 Jan 11)


New feature : Conditional Authentication Support using JavaScript
<https://github.com/wso2/carbon-identity-framework/issues/1253>

<https://github.com/wso2/product-is/milestone/11?closed=1>
Contribute to WSO2 Identity ServerMailing 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
   <http://stackoverflow.com/questions/tagged/wso2is>

Reporting Issues

We encourage you to report issues, improvements, and feature requests
regarding WSO2 Identity Server through our public WSO2 Identity Server GIT
Issues <https://github.com/wso2/product-is/issues>.


~ The WSO2 Identity and Access Management Team ~


-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [IS] SCIM Support for Admin Users

[Sathya Bandara]

Hi all,

With the current user core implementation we do not include a SCIM user_id
for admin users (Since SCIM is not used in all products) which prevents
SCIM based CRUD operations on admin users. In order to implement this we
have identified the following two approaches.

*#option 1*

Generate admin users' SCIM userId in SCIM component activator at server
start up (for admin users in super tenant domain). For tenant admins we can
configure a listener on tenant admin creation in TenantMgtService[2] to
generate user_id if SCIM is enabled.

*#option 2*

In AbstractUserStoreManager [1] modify addInitialAdminData() operation to
apply SCIM user_id claim when adding a new admin user. For the default LDAP
admin we can check the already existing claims for the user_id claim and
generate a random id if it doesn't exist. For tenant admins this can be
done via the above mentioned listener. In this approach we expose SCIM on
all the other products which do not support SCIM since we implement this at
kernel level.

In my opinion, option 1 would be more suitable since in this approach we do
not need to additionally provide this feature on products that do not
support SCIM.

Highly appreciate your suggestions on this.

[1] https://github.com/wso2/carbon-kernel/blob/4.4.x/core/
org.wso2.carbon.user.core/src/main/java/org/wso2/carbon/user/core/common/
AbstractUserStoreManager.java#L3835
[2] https://github.com/wso2/carbon-multitenancy/blob/
master/components/tenant-mgt/org.wso2.carbon.tenant.mgt/
src/main/java/org/wso2/carbon/tenant/mgt/services/
TenantMgtAdminService.java#L57


Thanks,
Sathya
-- 
Sathya Bandara
Software Engineer
WSO2 Inc. http://wso2.com
Mobile: (+94) 715 360 421 <+94%2071%20411%205032>

<+94%2071%20411%205032>
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

Re: [Architecture] JMS Transport Support for BPMN

[Sathya Bandara]

Hi Hasitha,

Currently we are using AUTO_ACK as the acknowledgement type. This is
because there are limitations in using client acknowledgements in BPMN.
Thanks for the suggestions.



On Wed, Dec 2, 2015 at 11:48 AM, Hasitha Hiranya <hasit...@wso2.com> wrote:

> Hi Dilini,
>
> What is the Acknowledgement Type you are hoping to use here?
> Or is it configurable?
>
> Acknowledgment type changes the way JMS messages are acked. Once acked,
> message is getting removed from the queue. i.e if you use AUTO_ACK message
> will be acked no matter processing failed or not. If you need to preserve
> message (and maybe re-try), you should consider other acknowledgement types.
>
>
> http://wso2.com/library/articles/2013/01/jms-message-delivery-reliability-acknowledgement-patterns/
>
> Thanks
>
> On Wed, Dec 2, 2015 at 11:41 AM, Dilini Mihindra <dili...@wso2.com> wrote:
>
>> Hi,
>>
>> WSO2 BPS already contains a RESTInvokerTask to send a message from a BPMN
>> process instance to a REST service. Similarly, we can provide a JMS
>> transport support for BPMN. This includes the following tasks:
>>
>>   * - JMSStartEvent*
>>This activity consists of a reference to an external JMS manager
>> configuration and specific queue information for the given process to
>> listen to.
>>
>> *- JMSMessageEvent *
>>  Similar to the StartActiviti, but this has to include correlation
>> processing logic in addition to the above start event properties.
>>
>>*-JMSInvokerTask*
>> This is similar to RESTInvoker Task where, from the BPMN process
>> instance, we will be putting a message into a pre-configured JMS queue
>> or a topic.
>>
>> JMS provides a reliable way of communicating messages among clients and
>> the receiving clients do not need to be online to retrieve messages.
>> Currently, we are implementing the JMSInvokerTask. The following diagram
>> depicts this:
>>
>> [image: Inline image 1]
>>
>> Best Regards,
>>
>> Dilini Mihindra Mampitiya Arachchi
>> Intern - Software Engineer
>> Mobile: +94 710 420 550
>> Email: dili...@wso2.com
>>
>> ___
>> Architecture mailing list
>> Architecture@wso2.org
>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>
>>
>
>
> --
> *Hasitha Abeykoon*
> Senior Software Engineer; WSO2, Inc.; http://wso2.com
> *cell:* *+94 719363063*
> *blog: **abeykoon.blogspot.com* <http://abeykoon.blogspot.com>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Sathya Bandara*
Software Engineering Intern
Email: sat...@wso2.com
Mobile: +94 715 360 421
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture