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

[Farasath Ahamed]

+1
I think this is a MUST have feature if are to move the IS runtime into
cloud.

Think about a scenario where we need to import Service Provider public
certificates for SAML Authentication request validation. If we do not
support reloading keystore dynamically we need to restart everynode
everytime we do a cert upload.

We can't afford to restart the nodes everytime we upload a SP cert in a
cloud environment.

On Friday, October 6, 2017, Sanjeewa Malalgoda  wrote:

> +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  > 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 - *+9476950*
>> Blog - *http://nallaa.wordpress.com *
>>
>
>
>
> --
>
> *Sanjeewa Malalgoda*
> WSO2 Inc.
> Mobile : +94713068779
>
> blog :http://sanjeewamalalgoda.
> blogspot.com/ 
>
>
>

-- 
Farasath Ahamed
Software Engineer, WSO2 Inc.; http://wso2.com
Mobile: +94777603866
Blog: blog.farazath.com
Twitter: @farazath619 

___
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

[Sanjeewa Malalgoda]

+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  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 - *+9476950*
> Blog - *http://nallaa.wordpress.com *
>



-- 

*Sanjeewa Malalgoda*
WSO2 Inc.
Mobile : +94713068779

blog
:http://sanjeewamalalgoda.blogspot.com/

___
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] [IAM] Adding/Reloading X509 Certificates at Runtime without Restart

[Asela Pathberiya]

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?

>
>- 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 ?



> 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
 +358 449 228 979

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