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>*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
