[Architecture] WSO2 Identity Server 5.4.0 Alpha5 Released!

[Dinali Dabarera]

The WSO2 Identity and Access Management team is pleased to announce the
release of WSO2 Identity Server 5.4.0 Alpha5. This distribution can be
downloaded from the following location.

https://github.com/wso2/product-is/releases/tag/v5.4.0-alpha5

The following list contains all the features, improvements, and bug fixes
available with the 5.4.0 Alpha5 release.

Patch

   - [IDENTITY-6482 ] - Issues
   in SCIM user update (PUT)
   - [IDENTITY-6517 ] - When
   adding more that two Destination URLs of residenti IDP in a tenant,
   Destination URLs configured in other tenants get removed from DB

Bug

   - [IDENTITY-6321 ] -
   Incorrect error messages in SCIM 2 exceptions.
   - [IDENTITY-6326 ] - Unable
   to create user with "email verification" and "request password" using SCIM
   - [IDENTITY-6479 ] - Secure
   /scim2/Me POST method by default
   - [IDENTITY-6481 ] - Fix
   issues related to SMS OTP
   - [IDENTITY-6541 ] - SCIM2
   filtering not working when the attribute value has underscore characters
   - [IDENTITY-6554 ] - SCIM2
   /Me GET with OAuth 2 token does not work
   - [IDENTITY-6556 ] -
   Accented characters are not rendered correctly in email templates
   - [IDENTITY-6602 ] - The
   facebook authenticator cannot set the subject claim from idp configuration

Task

   - [IDENTITY-6526 ] - Improve
   unit tests coverage for identity-base
   - [IDENTITY-6530 ] - Improve
   unit tests coverage for identity-local-auth-basicauth repo
   - [IDENTITY-6531 ] - Improve
   unit tests coverage for identity-local-auth-iwa-kerberos repo
   - [IDENTITY-6535 ] - Improve
   unit tests coverage for identity-outbound-auth-facebook repo

Improvement

   - [IDENTITY-5424 ] - Ability
   to Configure Regex Patterns for Callback URLs when working with OIDC
   Session Management



*How To Contribute*
Your feedback is most welcome!
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, and feature requests
regarding WSO2 Identity Server through public WSO2 Identity Server JIRA
.


*~ The WSO2 Identity and Access Management Team ~*


-- 
*Dinali Rosemin Dabarera*
Software Engineer
WSO2 Lanka (pvt) Ltd.
Web: http://wso2.com/
Email : gdrdabar...@gmail.com
LinkedIn 
Mobile: +94770198933





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

Re: [Architecture] [IAM] Adding/Reloading X509 Certificates at Runtime without Restart

[Johann Nallathamby]

Hi Asela,

On Wed, Oct 4, 2017 at 7:38 PM, Asela Pathberiya  wrote:

>
>
> On Sat, Sep 9, 2017 at 11:57 AM, Johann Nallathamby 
> wrote:
>
>> Hi IAM Team,
>>
>> The current keystore management functionalities of Carbon Server are
>> provided by the security-mgt bundle. The features include,
>>
>>- Adding new key stores
>>- Adding/Removing certificates to key stores (including the carbon
>>server default key store)
>>
>> For the admin user the UI displays the carbon server key store
>> (wso2-carbon.jks by default). The certificates and private key in this key
>> store is used to sign and verify SSO requests etc. Additionally the server
>> comprises of a trust store (client-truststore.jks by default) that is used
>> to verify hosts (much like a web browser verifies websites) - this trust
>> store is used during processes like OpenID Connect to verify the identity
>> of authorization server etc.
>>
>> Current Limitations include:
>>
>>- Client-truststore.jks is not displayed on the UI - so if one needs
>>to add certificates to the trust store one will have to do it externally
>>[1].
>>- There is no option to add additional trust stores - only key stores
>>that includes a private key are allowed to be added.
>>- In order for the changes to take effect the server needs to be
>>restarted. [1]
>>
>> As the solution we have to:
>>
>>- Alter UI to view the default trust store
>>- Alter keystore management service to support the addition of trust
>>stores
>>
>> Why do we need multiple trust stores  support?
>

There may be no urgent requirement for this. But when doing the improvement
to show the default client-truststore.jks we can't special case it. We have
to make it generic to align with the Keystore Management feature. Hence we
provided the ability to upload new truststores also.

The difference between truststores and keystores in the Keystore Management
feature is that keystores must have one private key. Truststores don't need
to have one.

However if you think of it, it can be useful to have this utility to manage
multiple truststores, so that each feature can use it's own truststore as
I've listed above. Another useful feature I've missed to list is the
truststore for user certificates in X509 authentication. It will be very
useful to separate out trusted user certificates from trusted CA
certificates. Therefore it's completely up to the individual features to
decide whether they want to use a dedicated truststore or not.

>
>>- 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.
>>
>> Sorry!  It is not clear how do we feed this changes to HTTP client
> implementation Does it require to change all the places which uses HTTP
> client ?
>

Yes. This should be ideally a Kernel utility provided and mandated for all
products to use. Currently since there are no improvements being done on
Kernel and all the products are mostly focussing on their next generation,
it will be good if we can add this at least to IS if we see this useful for
IS 5.x.x.

Regards,
Johann.


>
>
>
>> Above changes were made on pull request [2].
>>
>
>> Why we couldn't merge this feature earlier was that we hadn't developed a
>> solution to sync this change from node to all nodes in the cluster. At the
>> time of this development our syncing mechanism was primarily svn based
>> deployment synchronization. However now we recommend deployment
>> synchronization as the last option. Our preferred options are NFS file
>> mount and r-sync. In such cases syncing is taken care by the
>> infrastructure. So this solution seems to be good enough. This is the same
>> case with secondary user stores as well.
>>
>> Although this use case is more prevalent in products such as ESB or API
>> Manager, in IS I see following use cases.
>>
>> 1. Connecting to a LDAP backend via over SSL.
>> 2. Connecting to a HTTP backend over SSL/TLS. E.g. OpenID Connect Token
>> Endpoint call
>> 3. Provisioning connectors (SCIM, DuoSecurity, etc.)
>> 4. Connecting to 3rd party SMS services. E.g. Nexmo.
>>
>> Is this something we see valuable that can be added to IS 5.4.0 or 5.5.0?
>>
>> [1] https://wso2.org/jira/browse/IDENTITY-1131
>> [2] https://github.com/wso2/carbon-identity/pull/1511
>>
>> Thanks & Regards,
>> Johann.
>>
>> --
>>
>> *Johann Dilantha Nallathamby*
>> Senior Lead Solutions Engineer
>> WSO2, Inc.
>> lean.enterprise.middleware
>>
>> Mobile - *+9476950*
>> Blog - *http://nallaa.wordpress.com *
>>
>
>
>
> --
> Thanks & Regards,
> Asela
>
> ATL
> Mobile : +94 777 625 933 <+94%2077%20762%205933>
>  +358 449 228 979
>
> http://soasecurity.org/
> http://xacmlinfo.org/
>



-- 
Thanks & Regards,

*Johann Dilantha 

Re: [Architecture] Metadata model for supporting edge nodes in an IoT deployment

[Nuwan Jayawardene]

Monthly update:

*The previous state of the project was put on hold to perform a design
review and proceed forward with any feedback received.*

As the progress of the project stands right now the following has been
implemented on the end of the IoT server;

1) Held design review and gained feedback with regards to changes that need
to be done on the implementation so far
2) Implemented desired changes and redid project from scratch to match new
requirements
3) Selected suitable library for the visualization of the network
hierarchy. Studied the required data structure needed for the visualization
4) Successfully completed APIs with data structure needed for the library

Work in progress at the time of writing is as follows;

1) Building the UI component such that a preliminary visualization can be
done before moving onto fine tuning and advanced work.

End of month goals;

1) Having workable UI providing Device Organization information
2) Finalizing required APIs and adding new ones according to the
requirements of the UI

On Fri, Sep 1, 2017 at 3:12 PM, Nuwan Jayawardene  wrote:

> Monthly update:
>
> As the progress of the project stands right now the following has been
> implemented on the end of the IoT server;
>
> 1) Main APIs have been implemented and published
> 2) Integration test scripts were written
> 3) Integration tests run and build successful
>
> Work in progress at the time of writing is as follows;
>
> 1) Understanding the UUF framework to develop the UI component
>
> End of month goals;
>
> 1) Having workable UI providing Device Organization information
> 2) Finalizing required APIs and adding new ones according to the
> requirements of the UI
>
> On Wed, Aug 23, 2017 at 2:14 PM, Nuwan Jayawardene 
> wrote:
>
>> Monthly update:
>>
>> As the progress of the project stands right now the following has been
>> implemented on the end of the IoT server;
>>
>> 1) Device organization database tables and DAO functionality
>> 2) Unit tests for the Device Organization DAO functionality tested and
>> builds successful
>> 3) OSGi service implemented and APIs published exposing the Device
>> Organization meta data handling operations
>>
>> Work in progress at the time of writing is as follows;
>>
>> 1) Implementing and publishing each individual API and checking for
>> errors and issues
>>
>> End of month goals;
>>
>> 1) Write integration tests to check APIs when building the final pack
>>
>> On Fri, Jul 28, 2017 at 3:13 PM, Nuwan Jayawardene 
>> wrote:
>>
>>> Overview
>>>
>>> As the product stands right now, WSO2 IoT Server only has the capability
>>> to detect and manage devices in direct connection with it. It has no
>>> capability to detect nor manage any device(s) connected via one or a
>>> network of IoT gateways. Providing this capability to the IoT server will
>>> give us benefits in the long run such as;
>>>
>>>
>>>1.
>>>
>>>Enabling more efficient edge analytics.
>>>2.
>>>
>>>Enabling legacy devices to connect to IoT server thus widening
>>>applicable use cases and scope.
>>>3.
>>>
>>>Enabling better organizational structure to a complex network of
>>>devices.
>>>4.
>>>
>>>Enabling more security features to be added locally (to gateways) as
>>>well as to IoTS itself.
>>>5.
>>>
>>>Enabling M2M connectivity features.
>>>
>>>
>>> Current state
>>>
>>> The project I am currently working on is based on programming the
>>> capability for IoTS server to detect and manage edge devices connected
>>> through a IoT gateway or a series of gateways.
>>>
>>> This will be achieved by making modifications to the agents running on
>>> edge devices as well as the gateway to gather additional metadata along
>>> with modifications on the server side to retrieve and process this meta
>>> data.
>>>
>>>
>>> *High level view of architecture*
>>>
>>> [image: High-level architecture.png]
>>>
>>>
>>> In the case of edge devices the modifications will allow for detection
>>> of any parent device they are connected to. In the case of the IoT gateway,
>>> the modifications will allow for the detection of a parent device as well
>>> as child devices connected to it.
>>>
>>>
>>> *Development phases*
>>>
>>>
>>>
>>> Phases
>>>
>>> Deliverables
>>>
>>> State
>>>
>>> Phase 1
>>>
>>> Developing gateway agent to store metadata on connected devices
>>>
>>> (On hold)
>>>
>>> Developing an edge device agent to communicate with gateway
>>>
>>> To be developed
>>>
>>> Developing IoTS side capability to interface with gateway and understand
>>> metadata.
>>>
>>> In progress
>>>
>>> Phase 2
>>>
>>> Develop IoTS side capability to map networked devices
>>>
>>> To be developed
>>>
>>> Develop visual dashboard to view connected devices in UI
>>>
>>> To be developed
>>>
>>> Develop capability for fault detection of an edge device
>>>
>>> To be developed
>>>
>>> Phase 3
>>>
>>> Research and develop M2M connectivity functionality to both