+1. We are seeing this limitation in API Manager as well. It would be great if we can have this feature ASAP.
Thanks, sanjeewa. On Sat, Sep 9, 2017 at 11:57 AM, Johann Nallathamby <joh...@wso2.com> 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 > - 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. > > 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>* > -- *Sanjeewa Malalgoda* WSO2 Inc. Mobile : +94713068779 <http://sanjeewamalalgoda.blogspot.com/>blog :http://sanjeewamalalgoda.blogspot.com/ <http://sanjeewamalalgoda.blogspot.com/>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
