Hi Asela, On Wed, Oct 4, 2017 at 7:38 PM, Asela Pathberiya <[email protected]> wrote:
> > > On Sat, Sep 9, 2017 at 11:57 AM, Johann Nallathamby <[email protected]> > 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 - *+94777776950* >> Blog - *http://nallaa.wordpress.com <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 Nallathamby* Senior Lead Solutions Engineer WSO2, Inc. lean.enterprise.middleware Mobile - *+94777776950* Blog - *http://nallaa.wordpress.com <http://nallaa.wordpress.com>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
