Re: [Architecture] [Feature] Storing the application certificate in the database.

[Kamidu Punchihewa]

Hi Rushmin/ Shazni,

+1 for storing the certificates in the database.
Regarding the User Experience aspected discussed above, IMHO I think its
better to provide both the option where a user can select the file as in
uploading a file and same as allowing user to input the certificate content
into an editor. A user will have two options so they can use most familiar
and convenient method to them.

Uploading a file needs a file name and the filename is an unwated data in
> our case


Since uploading file will have unwanted data to be saved, we can read the
file using front-end scripting and view the certificate contains in the
text editor which users can type or past the certificate data. Then we just
have to send the certificate data to the backend and handle only the needed
information. WDYT?


Thanks and Best Regards,

On Sun, Jan 14, 2018 at 10:31 AM, Inosh Perera  wrote:

> Hi Rushmin,
>
> The certificate should be stored in the database so that it is shared and
> a restart is not needed.
> +1 for the approach. There is a similar implementation[1] in the IoT
> server to maintain device identity certificates of the devices for auto
> enrollment flows. However, since the client we are using(device agents) are
> provided by the IoT server, the in-build CA of the IoT server creates per
> device certificates for each device, therefore, we are doing mutual TLS.
> However, you may still be able to use some of the logic.
>
> [1]. https://github.com/wso2/carbon-device-mgt/tree/master/c
> omponents/certificate-mgt
>
> Regards,
> Inosh
>
> On Mon, Jan 8, 2018 at 9:39 PM, Shazni Nazeer  wrote:
>
>> Yes. Seems both options are viable and has it own pros and cons. I'm +1
>> for either option. Just that uploading is little more convenient at the
>> time of adding it. But having text have its own reason to consider it.
>>
>> On Sun, Jan 7, 2018 at 11:22 PM, Rushmin Fernando 
>> wrote:
>>
>>>
>>>
>>> On Mon, Jan 8, 2018 at 3:19 AM, Shazni Nazeer  wrote:
>>>
 1) The SP UI will have a new text area to enter the certificate in PEM
 format.
 Is there any specific reason to use text area here? In IDP UI, we
 have an option to upload the idp cert. IMO it is better to have that 
 option
 in SP UI as well for the UI consistance. '

>>>

> It is bit easier for users to paste the content staight away rather
 than uploading files.
 +1 for making both UIs consistent.
>>>
>>>
 +! for certificate upload mechanism for consistency. I think uploading
 will be much easier than pasting the text.

>>>
>>>
>>>
>>> Thank you for the feedback Shazni. I agree that uploading might be
>>> eaiser when you have the file in hand. But we have following cons as well
>>> given that a PEM encoded ceritificate is a text content which is about 10
>>> lines.
>>>
>>>
>>> 1) Uploading a file needs a file name and the filename is an unwated
>>> data in our case.
>>>
>>> 2) If you want to view the uploaded PEM file later, you have to download
>>> it. (It is cleaner when you see the content in the UI)
>>>
>>>
>>>
>>>


 Also if the user can still add the certificate of the SP to the
 keystore and also from the UI, what would be the behavior when one of the
 certificate is invalid or expired and the other one is correct? Will there
 be any precedence, such as if it's in DB it will only check in DB or
 whether it checks in both DB and keystore?

 On Sat, Jan 6, 2018 at 6:37 AM, Godwin Shrimal  wrote:

> Thanks for the explanation Rushmin. Yeah, it makes sense. +1
>
>
> Thanks
> Godwin
>
> On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando 
> wrote:
>
>> Hi Godwin,
>>
>> IMO certificate is a first class member of a service provider. So
>> storing it as a field in SP_APP is cleaner.
>>
>> On the other hand, the datatype of a certificate doesn't really go
>> with other metadata.
>>
>> In the best case, we have to alter the metadata table to hold a
>> VARCHAR of like 1000 characters.
>>
>> Considering all of these facts, I thought of using the SP_APP table
>> instead of SP_METADATA.
>>
>> What do you think?
>>
>> On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal 
>> wrote:
>>
>>> Hi Rushmin,
>>>
>>> Any reason to use SP_APP table to persist the certificate? We have a
>>> table called SP_METADATA to SP related metadata. I think we can use that
>>> table without changing any DB Schema. WDYT?
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando 
>>> wrote:
>>>


 On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
 wrote:

> Hi Rushmin,

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Inosh Perera]

Hi Rushmin,

The certificate should be stored in the database so that it is shared and a
restart is not needed.
+1 for the approach. There is a similar implementation[1] in the IoT server
to maintain device identity certificates of the devices for auto enrollment
flows. However, since the client we are using(device agents) are provided
by the IoT server, the in-build CA of the IoT server creates per device
certificates for each device, therefore, we are doing mutual TLS. However,
you may still be able to use some of the logic.

[1]. https://github.com/wso2/carbon-device-mgt/tree/master/
components/certificate-mgt

Regards,
Inosh

On Mon, Jan 8, 2018 at 9:39 PM, Shazni Nazeer  wrote:

> Yes. Seems both options are viable and has it own pros and cons. I'm +1
> for either option. Just that uploading is little more convenient at the
> time of adding it. But having text have its own reason to consider it.
>
> On Sun, Jan 7, 2018 at 11:22 PM, Rushmin Fernando 
> wrote:
>
>>
>>
>> On Mon, Jan 8, 2018 at 3:19 AM, Shazni Nazeer  wrote:
>>
>>> 1) The SP UI will have a new text area to enter the certificate in PEM
>>> format.
>>> Is there any specific reason to use text area here? In IDP UI, we
>>> have an option to upload the idp cert. IMO it is better to have that 
>>> option
>>> in SP UI as well for the UI consistance. '
>>>
>>
>>>
 It is bit easier for users to paste the content staight away rather
>>> than uploading files.
>>> +1 for making both UIs consistent.
>>
>>
>>> +! for certificate upload mechanism for consistency. I think uploading
>>> will be much easier than pasting the text.
>>>
>>
>>
>>
>> Thank you for the feedback Shazni. I agree that uploading might be eaiser
>> when you have the file in hand. But we have following cons as well given
>> that a PEM encoded ceritificate is a text content which is about 10 lines.
>>
>>
>> 1) Uploading a file needs a file name and the filename is an unwated data
>> in our case.
>>
>> 2) If you want to view the uploaded PEM file later, you have to download
>> it. (It is cleaner when you see the content in the UI)
>>
>>
>>
>>
>>>
>>>
>>> Also if the user can still add the certificate of the SP to the keystore
>>> and also from the UI, what would be the behavior when one of the
>>> certificate is invalid or expired and the other one is correct? Will there
>>> be any precedence, such as if it's in DB it will only check in DB or
>>> whether it checks in both DB and keystore?
>>>
>>> On Sat, Jan 6, 2018 at 6:37 AM, Godwin Shrimal  wrote:
>>>
 Thanks for the explanation Rushmin. Yeah, it makes sense. +1


 Thanks
 Godwin

 On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando 
 wrote:

> Hi Godwin,
>
> IMO certificate is a first class member of a service provider. So
> storing it as a field in SP_APP is cleaner.
>
> On the other hand, the datatype of a certificate doesn't really go
> with other metadata.
>
> In the best case, we have to alter the metadata table to hold a
> VARCHAR of like 1000 characters.
>
> Considering all of these facts, I thought of using the SP_APP table
> instead of SP_METADATA.
>
> What do you think?
>
> On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal 
> wrote:
>
>> Hi Rushmin,
>>
>> Any reason to use SP_APP table to persist the certificate? We have a
>> table called SP_METADATA to SP related metadata. I think we can use that
>> table without changing any DB Schema. WDYT?
>>
>>
>> Thanks
>> Godwin
>>
>> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Rushmin,

 On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
 hasan...@wso2.com> wrote:

> Hi Rushmin,
>
> *How is this done now?*
>>
>> The application certificate should be imported to the keystore file
>> and the alias should be mentioned in the service provider so
>> that the service provider can validate the signature against the
>> certificate identified by that alias.
>>
>
> If we have the current option of  importing the certificate to the
> keystore, in JWT client authentication [1] we have to provide the
> certificate alias as the client id inorder to identify the 
> application. So
> with this implementation we don't need to enforce end users to do the 
> above
> as we can fetch the client_id directly from the db.
>
> +1 for the approach.
>
> [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0
>

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Shazni Nazeer]

Yes. Seems both options are viable and has it own pros and cons. I'm +1 for
either option. Just that uploading is little more convenient at the time of
adding it. But having text have its own reason to consider it.

On Sun, Jan 7, 2018 at 11:22 PM, Rushmin Fernando  wrote:

>
>
> On Mon, Jan 8, 2018 at 3:19 AM, Shazni Nazeer  wrote:
>
>> 1) The SP UI will have a new text area to enter the certificate in PEM
>> format.
>> Is there any specific reason to use text area here? In IDP UI, we
>> have an option to upload the idp cert. IMO it is better to have that 
>> option
>> in SP UI as well for the UI consistance. '
>>
>
>>
>>> It is bit easier for users to paste the content staight away rather than
>> uploading files.
>> +1 for making both UIs consistent.
>
>
>> +! for certificate upload mechanism for consistency. I think uploading
>> will be much easier than pasting the text.
>>
>
>
>
> Thank you for the feedback Shazni. I agree that uploading might be eaiser
> when you have the file in hand. But we have following cons as well given
> that a PEM encoded ceritificate is a text content which is about 10 lines.
>
>
> 1) Uploading a file needs a file name and the filename is an unwated data
> in our case.
>
> 2) If you want to view the uploaded PEM file later, you have to download
> it. (It is cleaner when you see the content in the UI)
>
>
>
>
>>
>>
>> Also if the user can still add the certificate of the SP to the keystore
>> and also from the UI, what would be the behavior when one of the
>> certificate is invalid or expired and the other one is correct? Will there
>> be any precedence, such as if it's in DB it will only check in DB or
>> whether it checks in both DB and keystore?
>>
>> On Sat, Jan 6, 2018 at 6:37 AM, Godwin Shrimal  wrote:
>>
>>> Thanks for the explanation Rushmin. Yeah, it makes sense. +1
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando 
>>> wrote:
>>>
 Hi Godwin,

 IMO certificate is a first class member of a service provider. So
 storing it as a field in SP_APP is cleaner.

 On the other hand, the datatype of a certificate doesn't really go with
 other metadata.

 In the best case, we have to alter the metadata table to hold a VARCHAR
 of like 1000 characters.

 Considering all of these facts, I thought of using the SP_APP table
 instead of SP_METADATA.

 What do you think?

 On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal 
 wrote:

> Hi Rushmin,
>
> Any reason to use SP_APP table to persist the certificate? We have a
> table called SP_METADATA to SP related metadata. I think we can use that
> table without changing any DB Schema. WDYT?
>
>
> Thanks
> Godwin
>
> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando 
> wrote:
>
>>
>>
>> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
>> wrote:
>>
>>> Hi Rushmin,
>>>
>>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
 Hi Rushmin,

 *How is this done now?*
>
> The application certificate should be imported to the keystore file
> and the alias should be mentioned in the service provider so that
> the service provider can validate the signature against the
> certificate identified by that alias.
>

 If we have the current option of  importing the certificate to the
 keystore, in JWT client authentication [1] we have to provide the
 certificate alias as the client id inorder to identify the 
 application. So
 with this implementation we don't need to enforce end users to do the 
 above
 as we can fetch the client_id directly from the db.

 +1 for the approach.

 [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0

 Thanks,

 On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando  wrote:

>
> In the identity server, a service provider represents the
> application which uses the Identity Server as an Identity Provider.
>
> In some cases, Identity Server needs to validate the identity of
> the application to make sure the authentication/authorization 
> requests are
> coming from the legitimate application.
>
> *How is this done now?*
>
> The application certificate should be imported to the
> keystore file and the alias should be mentioned in the service 
> provider so
> that the service provider can validate the signature against the
> certificate identified by that 

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Shazni Nazeer]

Hi Ruwan,

Obviously that makes sense.

I was only contemplating a situation where the DB has the incorrect certs
and the keystore has the correct one and someone getting confused why the
request fails. But this is just an edge case I suppose. If we have the
logic clearly mentioned clearly in the docs I think we can eliminate any
confusion.

On Sun, Jan 7, 2018 at 7:38 PM, Ruwan Abeykoon  wrote:

> Hi Shazni,
> I think we need only use if the certificate in single place. It should
> validate only in DB if one available in DB, and should not check the file
> based store.
> We only retain the file based strore for backward compatibility.
> Resons,
> 1. It will be easy for the end user to update the certificate when it
> expires(only at DB)
> 2. It is easy to explain in docs and less error prone(not much complexity)
> 3. Easy on support front, because there are no *if then X else if Y else
> Z" checks.
>
> Cheers,
> Ruwan
>
> On Mon, Jan 8, 2018 at 3:19 AM, Shazni Nazeer  wrote:
>
>> 1) The SP UI will have a new text area to enter the certificate in PEM
>> format.
>> Is there any specific reason to use text area here? In IDP UI, we
>> have an option to upload the idp cert. IMO it is better to have that 
>> option
>> in SP UI as well for the UI consistance. '
>>
>
>>
>>> It is bit easier for users to paste the content staight away rather than
>> uploading files.
>> +1 for making both UIs consistent.
>
>
>> +! for certificate upload mechanism for consistency. I think uploading
>> will be much easier than pasting the text.
>>
>> Also if the user can still add the certificate of the SP to the keystore
>> and also from the UI, what would be the behavior when one of the
>> certificate is invalid or expired and the other one is correct? Will there
>> be any precedence, such as if it's in DB it will only check in DB or
>> whether it checks in both DB and keystore?
>>
>> On Sat, Jan 6, 2018 at 6:37 AM, Godwin Shrimal  wrote:
>>
>>> Thanks for the explanation Rushmin. Yeah, it makes sense. +1
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando 
>>> wrote:
>>>
 Hi Godwin,

 IMO certificate is a first class member of a service provider. So
 storing it as a field in SP_APP is cleaner.

 On the other hand, the datatype of a certificate doesn't really go with
 other metadata.

 In the best case, we have to alter the metadata table to hold a VARCHAR
 of like 1000 characters.

 Considering all of these facts, I thought of using the SP_APP table
 instead of SP_METADATA.

 What do you think?

 On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal 
 wrote:

> Hi Rushmin,
>
> Any reason to use SP_APP table to persist the certificate? We have a
> table called SP_METADATA to SP related metadata. I think we can use that
> table without changing any DB Schema. WDYT?
>
>
> Thanks
> Godwin
>
> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando 
> wrote:
>
>>
>>
>> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
>> wrote:
>>
>>> Hi Rushmin,
>>>
>>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
 Hi Rushmin,

 *How is this done now?*
>
> The application certificate should be imported to the keystore file
> and the alias should be mentioned in the service provider so that
> the service provider can validate the signature against the
> certificate identified by that alias.
>

 If we have the current option of  importing the certificate to the
 keystore, in JWT client authentication [1] we have to provide the
 certificate alias as the client id inorder to identify the 
 application. So
 with this implementation we don't need to enforce end users to do the 
 above
 as we can fetch the client_id directly from the db.

 +1 for the approach.

 [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0

 Thanks,

 On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando  wrote:

>
> In the identity server, a service provider represents the
> application which uses the Identity Server as an Identity Provider.
>
> In some cases, Identity Server needs to validate the identity of
> the application to make sure the authentication/authorization 
> requests are
> coming from the legitimate application.
>
> *How is this done now?*
>
> The application certificate should be imported to the
> keystore file and the 

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Ruwan Abeykoon]

Hi Shazni,
I think we need only use if the certificate in single place. It should
validate only in DB if one available in DB, and should not check the file
based store.
We only retain the file based strore for backward compatibility.
Resons,
1. It will be easy for the end user to update the certificate when it
expires(only at DB)
2. It is easy to explain in docs and less error prone(not much complexity)
3. Easy on support front, because there are no *if then X else if Y else Z"
checks.

Cheers,
Ruwan

On Mon, Jan 8, 2018 at 3:19 AM, Shazni Nazeer  wrote:

> 1) The SP UI will have a new text area to enter the certificate in PEM
> format.
> Is there any specific reason to use text area here? In IDP UI, we have
> an option to upload the idp cert. IMO it is better to have that option in
> SP UI as well for the UI consistance. '
>

>
>> It is bit easier for users to paste the content staight away rather than
> uploading files.
> +1 for making both UIs consistent.


> +! for certificate upload mechanism for consistency. I think uploading
> will be much easier than pasting the text.
>
> Also if the user can still add the certificate of the SP to the keystore
> and also from the UI, what would be the behavior when one of the
> certificate is invalid or expired and the other one is correct? Will there
> be any precedence, such as if it's in DB it will only check in DB or
> whether it checks in both DB and keystore?
>
> On Sat, Jan 6, 2018 at 6:37 AM, Godwin Shrimal  wrote:
>
>> Thanks for the explanation Rushmin. Yeah, it makes sense. +1
>>
>>
>> Thanks
>> Godwin
>>
>> On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando 
>> wrote:
>>
>>> Hi Godwin,
>>>
>>> IMO certificate is a first class member of a service provider. So
>>> storing it as a field in SP_APP is cleaner.
>>>
>>> On the other hand, the datatype of a certificate doesn't really go with
>>> other metadata.
>>>
>>> In the best case, we have to alter the metadata table to hold a VARCHAR
>>> of like 1000 characters.
>>>
>>> Considering all of these facts, I thought of using the SP_APP table
>>> instead of SP_METADATA.
>>>
>>> What do you think?
>>>
>>> On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal  wrote:
>>>
 Hi Rushmin,

 Any reason to use SP_APP table to persist the certificate? We have a
 table called SP_METADATA to SP related metadata. I think we can use that
 table without changing any DB Schema. WDYT?


 Thanks
 Godwin

 On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando 
 wrote:

>
>
> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
> wrote:
>
>> Hi Rushmin,
>>
>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> wrote:
>>
>>> Hi Rushmin,
>>>
>>> *How is this done now?*

 The application certificate should be imported to the keystore file
 and the alias should be mentioned in the service provider so that
 the service provider can validate the signature against the
 certificate identified by that alias.

>>>
>>> If we have the current option of  importing the certificate to the
>>> keystore, in JWT client authentication [1] we have to provide the
>>> certificate alias as the client id inorder to identify the application. 
>>> So
>>> with this implementation we don't need to enforce end users to do the 
>>> above
>>> as we can fetch the client_id directly from the db.
>>>
>>> +1 for the approach.
>>>
>>> [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0
>>>
>>> Thanks,
>>>
>>> On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando 
>>> wrote:
>>>

 In the identity server, a service provider represents the
 application which uses the Identity Server as an Identity Provider.

 In some cases, Identity Server needs to validate the identity of
 the application to make sure the authentication/authorization requests 
 are
 coming from the legitimate application.

 *How is this done now?*

 The application certificate should be imported to the keystore file
 and the alias should be mentioned in the service provider so that the
 service provider can validate the signature against the certificate
 identified by that alias.

 *Why is this needs to be improved?*

 1) keystore file resides in the file system. Therefore in a
 clustered deployment, either the certificate should be added to all the
 nodes or the keystore file should be synced.

 2) The server needs a restart after importing a certificate.

 *What is the solution?*

 

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Shazni Nazeer]

>
> 1) The SP UI will have a new text area to enter the certificate in PEM
 format.
 Is there any specific reason to use text area here? In IDP UI, we have
 an option to upload the idp cert. IMO it is better to have that option in
 SP UI as well for the UI consistance. '

>>>

> It is bit easier for users to paste the content staight away rather than
 uploading files.
 +1 for making both UIs consistent.
>>>
>>>
+! for certificate upload mechanism for consistency. I think uploading will
be much easier than pasting the text.

Also if the user can still add the certificate of the SP to the keystore
and also from the UI, what would be the behavior when one of the
certificate is invalid or expired and the other one is correct? Will there
be any precedence, such as if it's in DB it will only check in DB or
whether it checks in both DB and keystore?

On Sat, Jan 6, 2018 at 6:37 AM, Godwin Shrimal  wrote:

> Thanks for the explanation Rushmin. Yeah, it makes sense. +1
>
>
> Thanks
> Godwin
>
> On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando  wrote:
>
>> Hi Godwin,
>>
>> IMO certificate is a first class member of a service provider. So storing
>> it as a field in SP_APP is cleaner.
>>
>> On the other hand, the datatype of a certificate doesn't really go with
>> other metadata.
>>
>> In the best case, we have to alter the metadata table to hold a VARCHAR
>> of like 1000 characters.
>>
>> Considering all of these facts, I thought of using the SP_APP table
>> instead of SP_METADATA.
>>
>> What do you think?
>>
>> On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal  wrote:
>>
>>> Hi Rushmin,
>>>
>>> Any reason to use SP_APP table to persist the certificate? We have a
>>> table called SP_METADATA to SP related metadata. I think we can use that
>>> table without changing any DB Schema. WDYT?
>>>
>>>
>>> Thanks
>>> Godwin
>>>
>>> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando 
>>> wrote:
>>>


 On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
 wrote:

> Hi Rushmin,
>
> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi Rushmin,
>>
>> *How is this done now?*
>>>
>>> The application certificate should be imported to the keystore file
>>> and the alias should be mentioned in the service provider so that
>>> the service provider can validate the signature against the
>>> certificate identified by that alias.
>>>
>>
>> If we have the current option of  importing the certificate to the
>> keystore, in JWT client authentication [1] we have to provide the
>> certificate alias as the client id inorder to identify the application. 
>> So
>> with this implementation we don't need to enforce end users to do the 
>> above
>> as we can fetch the client_id directly from the db.
>>
>> +1 for the approach.
>>
>> [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0
>>
>> Thanks,
>>
>> On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando 
>> wrote:
>>
>>>
>>> In the identity server, a service provider represents the
>>> application which uses the Identity Server as an Identity Provider.
>>>
>>> In some cases, Identity Server needs to validate the identity of the
>>> application to make sure the authentication/authorization requests are
>>> coming from the legitimate application.
>>>
>>> *How is this done now?*
>>>
>>> The application certificate should be imported to the keystore file
>>> and the alias should be mentioned in the service provider so that the
>>> service provider can validate the signature against the certificate
>>> identified by that alias.
>>>
>>> *Why is this needs to be improved?*
>>>
>>> 1) keystore file resides in the file system. Therefore in a
>>> clustered deployment, either the certificate should be added to all the
>>> nodes or the keystore file should be synced.
>>>
>>> 2) The server needs a restart after importing a certificate.
>>>
>>> *What is the solution?*
>>>
>>> The certificate should be stored in the database so that it is
>>> shared and a restart is not needed.
>>>
>>> *High-level design/UX decisions*
>>>
>>> 1) The SP UI will have a new text area to enter the certificate in
>>> PEM format.
>>>
>> Is there any specific reason to use text area here? In IDP UI, we
> have an option to upload the idp cert. IMO it is better to have that 
> option
> in SP UI as well for the UI consistance.
>

 It is bit easier for users to paste the content staight away rather
 than uploading files.

 +1 for making both UIs consistent.


> Thanks
> Isura.
>
>>
>>> 2) The certificate will be stored 

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Godwin Shrimal]

Thanks for the explanation Rushmin. Yeah, it makes sense. +1


Thanks
Godwin

On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando  wrote:

> Hi Godwin,
>
> IMO certificate is a first class member of a service provider. So storing
> it as a field in SP_APP is cleaner.
>
> On the other hand, the datatype of a certificate doesn't really go with
> other metadata.
>
> In the best case, we have to alter the metadata table to hold a VARCHAR of
> like 1000 characters.
>
> Considering all of these facts, I thought of using the SP_APP table
> instead of SP_METADATA.
>
> What do you think?
>
> On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal  wrote:
>
>> Hi Rushmin,
>>
>> Any reason to use SP_APP table to persist the certificate? We have a
>> table called SP_METADATA to SP related metadata. I think we can use that
>> table without changing any DB Schema. WDYT?
>>
>>
>> Thanks
>> Godwin
>>
>> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando 
>> wrote:
>>
>>>
>>>
>>> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
>>> wrote:
>>>
 Hi Rushmin,

 On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
 hasan...@wso2.com> wrote:

> Hi Rushmin,
>
> *How is this done now?*
>>
>> The application certificate should be imported to the keystore file
>> and the alias should be mentioned in the service provider so that the 
>> service
>> provider can validate the signature against the certificate identified
>> by that alias.
>>
>
> If we have the current option of  importing the certificate to the
> keystore, in JWT client authentication [1] we have to provide the
> certificate alias as the client id inorder to identify the application. So
> with this implementation we don't need to enforce end users to do the 
> above
> as we can fetch the client_id directly from the db.
>
> +1 for the approach.
>
> [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0
>
> Thanks,
>
> On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando 
> wrote:
>
>>
>> In the identity server, a service provider represents the application
>> which uses the Identity Server as an Identity Provider.
>>
>> In some cases, Identity Server needs to validate the identity of the
>> application to make sure the authentication/authorization requests are
>> coming from the legitimate application.
>>
>> *How is this done now?*
>>
>> The application certificate should be imported to the keystore file
>> and the alias should be mentioned in the service provider so that the
>> service provider can validate the signature against the certificate
>> identified by that alias.
>>
>> *Why is this needs to be improved?*
>>
>> 1) keystore file resides in the file system. Therefore in a clustered
>> deployment, either the certificate should be added to all the nodes or 
>> the
>> keystore file should be synced.
>>
>> 2) The server needs a restart after importing a certificate.
>>
>> *What is the solution?*
>>
>> The certificate should be stored in the database so that it is shared
>> and a restart is not needed.
>>
>> *High-level design/UX decisions*
>>
>> 1) The SP UI will have a new text area to enter the certificate in
>> PEM format.
>>
> Is there any specific reason to use text area here? In IDP UI, we have
 an option to upload the idp cert. IMO it is better to have that option in
 SP UI as well for the UI consistance.

>>>
>>> It is bit easier for users to paste the content staight away rather than
>>> uploading files.
>>>
>>> +1 for making both UIs consistent.
>>>
>>>
 Thanks
 Isura.

>
>> 2) The certificate will be stored in the SP_APP table. A new column
>> will be added.
>>
>> *REASON*:
>>
>> Service provider --> certificate is a 1:1 relationship.
>>
>> 3) An interface will be introduced to abstract out the certificate
>> handling of the SP. Two implementations will be there to support the
>> current behavior and the proposed behavior.
>>
>> 4) Current behavior will be deprecated.
>>
>> 5) Choosing between the two implementations not explicit for the
>> users, so a configuration will not be provided. If a certificate is not
>> available in the database Identity Server will fall back to the current
>> approach.
>>
>> *REASON*:
>>
>> 1. This feature is about changing an internal implementation. So the
>> users should not worry about it.
>>
>>
>>
>> Please share your thoughts.
>>
>>
>>
>>
>> --
>> *Best Regards*
>>
>> *Rushmin Fernando*
>> *Technical Lead*
>>
>> WSO2 Inc.  - Lean . Enterprise . Middleware
>>
>> mobile : 

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Rushmin Fernando]

Hi Godwin,

IMO certificate is a first class member of a service provider. So storing
it as a field in SP_APP is cleaner.

On the other hand, the datatype of a certificate doesn't really go with
other metadata.

In the best case, we have to alter the metadata table to hold a VARCHAR of
like 1000 characters.

Considering all of these facts, I thought of using the SP_APP table instead
of SP_METADATA.

What do you think?

On Fri, Jan 5, 2018 at 12:56 PM, Godwin Shrimal  wrote:

> Hi Rushmin,
>
> Any reason to use SP_APP table to persist the certificate? We have a table
> called SP_METADATA to SP related metadata. I think we can use that table
> without changing any DB Schema. WDYT?
>
>
> Thanks
> Godwin
>
> On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando  wrote:
>
>>
>>
>> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne 
>> wrote:
>>
>>> Hi Rushmin,
>>>
>>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
>>> hasan...@wso2.com> wrote:
>>>
 Hi Rushmin,

 *How is this done now?*
>
> The application certificate should be imported to the keystore file
> and the alias should be mentioned in the service provider so that the 
> service
> provider can validate the signature against the certificate identified
> by that alias.
>

 If we have the current option of  importing the certificate to the
 keystore, in JWT client authentication [1] we have to provide the
 certificate alias as the client id inorder to identify the application. So
 with this implementation we don't need to enforce end users to do the above
 as we can fetch the client_id directly from the db.

 +1 for the approach.

 [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0

 Thanks,

 On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando 
 wrote:

>
> In the identity server, a service provider represents the application
> which uses the Identity Server as an Identity Provider.
>
> In some cases, Identity Server needs to validate the identity of the
> application to make sure the authentication/authorization requests are
> coming from the legitimate application.
>
> *How is this done now?*
>
> The application certificate should be imported to the keystore file
> and the alias should be mentioned in the service provider so that the
> service provider can validate the signature against the certificate
> identified by that alias.
>
> *Why is this needs to be improved?*
>
> 1) keystore file resides in the file system. Therefore in a clustered
> deployment, either the certificate should be added to all the nodes or the
> keystore file should be synced.
>
> 2) The server needs a restart after importing a certificate.
>
> *What is the solution?*
>
> The certificate should be stored in the database so that it is shared
> and a restart is not needed.
>
> *High-level design/UX decisions*
>
> 1) The SP UI will have a new text area to enter the certificate in PEM
> format.
>
 Is there any specific reason to use text area here? In IDP UI, we have
>>> an option to upload the idp cert. IMO it is better to have that option in
>>> SP UI as well for the UI consistance.
>>>
>>
>> It is bit easier for users to paste the content staight away rather than
>> uploading files.
>>
>> +1 for making both UIs consistent.
>>
>>
>>> Thanks
>>> Isura.
>>>

> 2) The certificate will be stored in the SP_APP table. A new column
> will be added.
>
> *REASON*:
>
> Service provider --> certificate is a 1:1 relationship.
>
> 3) An interface will be introduced to abstract out the certificate
> handling of the SP. Two implementations will be there to support the
> current behavior and the proposed behavior.
>
> 4) Current behavior will be deprecated.
>
> 5) Choosing between the two implementations not explicit for the
> users, so a configuration will not be provided. If a certificate is not
> available in the database Identity Server will fall back to the current
> approach.
>
> *REASON*:
>
> 1. This feature is about changing an internal implementation. So the
> users should not worry about it.
>
>
>
> Please share your thoughts.
>
>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc.  - Lean . Enterprise . Middleware
>
> mobile : +94775615183
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


 --

 Hasanthi Dissanayake

 Senior Software Engineer | WSO2

 E: 

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Godwin Shrimal]

Hi Rushmin,

Any reason to use SP_APP table to persist the certificate? We have a table
called SP_METADATA to SP related metadata. I think we can use that table
without changing any DB Schema. WDYT?


Thanks
Godwin

On Fri, Jan 5, 2018 at 1:33 PM, Rushmin Fernando  wrote:

>
>
> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne  wrote:
>
>> Hi Rushmin,
>>
>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
>> hasan...@wso2.com> wrote:
>>
>>> Hi Rushmin,
>>>
>>> *How is this done now?*

 The application certificate should be imported to the keystore file
 and the alias should be mentioned in the service provider so that the 
 service
 provider can validate the signature against the certificate identified
 by that alias.

>>>
>>> If we have the current option of  importing the certificate to the
>>> keystore, in JWT client authentication [1] we have to provide the
>>> certificate alias as the client id inorder to identify the application. So
>>> with this implementation we don't need to enforce end users to do the above
>>> as we can fetch the client_id directly from the db.
>>>
>>> +1 for the approach.
>>>
>>> [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0
>>>
>>> Thanks,
>>>
>>> On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando 
>>> wrote:
>>>

 In the identity server, a service provider represents the application
 which uses the Identity Server as an Identity Provider.

 In some cases, Identity Server needs to validate the identity of the
 application to make sure the authentication/authorization requests are
 coming from the legitimate application.

 *How is this done now?*

 The application certificate should be imported to the keystore file and
 the alias should be mentioned in the service provider so that the service
 provider can validate the signature against the certificate identified by
 that alias.

 *Why is this needs to be improved?*

 1) keystore file resides in the file system. Therefore in a clustered
 deployment, either the certificate should be added to all the nodes or the
 keystore file should be synced.

 2) The server needs a restart after importing a certificate.

 *What is the solution?*

 The certificate should be stored in the database so that it is shared
 and a restart is not needed.

 *High-level design/UX decisions*

 1) The SP UI will have a new text area to enter the certificate in PEM
 format.

>>> Is there any specific reason to use text area here? In IDP UI, we have
>> an option to upload the idp cert. IMO it is better to have that option in
>> SP UI as well for the UI consistance.
>>
>
> It is bit easier for users to paste the content staight away rather than
> uploading files.
>
> +1 for making both UIs consistent.
>
>
>> Thanks
>> Isura.
>>
>>>
 2) The certificate will be stored in the SP_APP table. A new column
 will be added.

 *REASON*:

 Service provider --> certificate is a 1:1 relationship.

 3) An interface will be introduced to abstract out the certificate
 handling of the SP. Two implementations will be there to support the
 current behavior and the proposed behavior.

 4) Current behavior will be deprecated.

 5) Choosing between the two implementations not explicit for the users,
 so a configuration will not be provided. If a certificate is not available
 in the database Identity Server will fall back to the current approach.

 *REASON*:

 1. This feature is about changing an internal implementation. So the
 users should not worry about it.



 Please share your thoughts.




 --
 *Best Regards*

 *Rushmin Fernando*
 *Technical Lead*

 WSO2 Inc.  - Lean . Enterprise . Middleware

 mobile : +94775615183



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


>>>
>>>
>>> --
>>>
>>> Hasanthi Dissanayake
>>>
>>> Senior Software Engineer | WSO2
>>>
>>> E: hasan...@wso2.com
>>> M :0718407133| http://wso2.com 
>>>
>>
>>
>>
>> --
>>
>> *Isura Dilhara Karunaratne*
>> Associate Technical Lead | WSO2
>> Email: is...@wso2.com
>> Mob : +94 772 254 810 <+94%2077%20225%204810>
>> Blog : http://isurad.blogspot.com/
>>
>>
>>
>>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc.  - Lean . Enterprise . Middleware
>
> mobile : +94775615183
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 
*Godwin Amila Shrimal*
Associate Technical Lead

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Rushmin Fernando]

On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne  wrote:

> Hi Rushmin,
>
> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake <
> hasan...@wso2.com> wrote:
>
>> Hi Rushmin,
>>
>> *How is this done now?*
>>>
>>> The application certificate should be imported to the keystore file and
>>> the alias should be mentioned in the service provider so that the service
>>> provider can validate the signature against the certificate identified
>>> by that alias.
>>>
>>
>> If we have the current option of  importing the certificate to the
>> keystore, in JWT client authentication [1] we have to provide the
>> certificate alias as the client id inorder to identify the application. So
>> with this implementation we don't need to enforce end users to do the above
>> as we can fetch the client_id directly from the db.
>>
>> +1 for the approach.
>>
>> [1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0
>>
>> Thanks,
>>
>> On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando 
>> wrote:
>>
>>>
>>> In the identity server, a service provider represents the application
>>> which uses the Identity Server as an Identity Provider.
>>>
>>> In some cases, Identity Server needs to validate the identity of the
>>> application to make sure the authentication/authorization requests are
>>> coming from the legitimate application.
>>>
>>> *How is this done now?*
>>>
>>> The application certificate should be imported to the keystore file and
>>> the alias should be mentioned in the service provider so that the service
>>> provider can validate the signature against the certificate identified by
>>> that alias.
>>>
>>> *Why is this needs to be improved?*
>>>
>>> 1) keystore file resides in the file system. Therefore in a clustered
>>> deployment, either the certificate should be added to all the nodes or the
>>> keystore file should be synced.
>>>
>>> 2) The server needs a restart after importing a certificate.
>>>
>>> *What is the solution?*
>>>
>>> The certificate should be stored in the database so that it is shared
>>> and a restart is not needed.
>>>
>>> *High-level design/UX decisions*
>>>
>>> 1) The SP UI will have a new text area to enter the certificate in PEM
>>> format.
>>>
>> Is there any specific reason to use text area here? In IDP UI, we have an
> option to upload the idp cert. IMO it is better to have that option in SP
> UI as well for the UI consistance.
>

It is bit easier for users to paste the content staight away rather than
uploading files.

+1 for making both UIs consistent.


> Thanks
> Isura.
>
>>
>>> 2) The certificate will be stored in the SP_APP table. A new column will
>>> be added.
>>>
>>> *REASON*:
>>>
>>> Service provider --> certificate is a 1:1 relationship.
>>>
>>> 3) An interface will be introduced to abstract out the certificate
>>> handling of the SP. Two implementations will be there to support the
>>> current behavior and the proposed behavior.
>>>
>>> 4) Current behavior will be deprecated.
>>>
>>> 5) Choosing between the two implementations not explicit for the users,
>>> so a configuration will not be provided. If a certificate is not available
>>> in the database Identity Server will fall back to the current approach.
>>>
>>> *REASON*:
>>>
>>> 1. This feature is about changing an internal implementation. So the
>>> users should not worry about it.
>>>
>>>
>>>
>>> Please share your thoughts.
>>>
>>>
>>>
>>>
>>> --
>>> *Best Regards*
>>>
>>> *Rushmin Fernando*
>>> *Technical Lead*
>>>
>>> WSO2 Inc.  - Lean . Enterprise . Middleware
>>>
>>> mobile : +94775615183
>>>
>>>
>>>
>>> ___
>>> Architecture mailing list
>>> Architecture@wso2.org
>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>>>
>>>
>>
>>
>> --
>>
>> Hasanthi Dissanayake
>>
>> Senior Software Engineer | WSO2
>>
>> E: hasan...@wso2.com
>> M :0718407133| http://wso2.com 
>>
>
>
>
> --
>
> *Isura Dilhara Karunaratne*
> Associate Technical Lead | WSO2
> Email: is...@wso2.com
> Mob : +94 772 254 810 <+94%2077%20225%204810>
> Blog : http://isurad.blogspot.com/
>
>
>
>


-- 
*Best Regards*

*Rushmin Fernando*
*Technical Lead*

WSO2 Inc.  - Lean . Enterprise . Middleware

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

Re: [Architecture] [Feature] Storing the application certificate in the database.

[Hasanthi Purnima Dissanayake]

Hi Rushmin,

*How is this done now?*
>
> The application certificate should be imported to the keystore file and
> the alias should be mentioned in the service provider so that the service
> provider can validate the signature against the certificate identified by
> that alias.
>

If we have the current option of  importing the certificate to the
keystore, in JWT client authentication [1] we have to provide the
certificate alias as the client id inorder to identify the application. So
with this implementation we don't need to enforce end users to do the above
as we can fetch the client_id directly from the db.

+1 for the approach.

[1] [IAM] JWT client authentication for OAuth 2.0 for IS 5.5.0

Thanks,

On Fri, Jan 5, 2018 at 11:31 AM, Rushmin Fernando  wrote:

>
> In the identity server, a service provider represents the application
> which uses the Identity Server as an Identity Provider.
>
> In some cases, Identity Server needs to validate the identity of the
> application to make sure the authentication/authorization requests are
> coming from the legitimate application.
>
> *How is this done now?*
>
> The application certificate should be imported to the keystore file and
> the alias should be mentioned in the service provider so that the service
> provider can validate the signature against the certificate identified by
> that alias.
>
> *Why is this needs to be improved?*
>
> 1) keystore file resides in the file system. Therefore in a clustered
> deployment, either the certificate should be added to all the nodes or the
> keystore file should be synced.
>
> 2) The server needs a restart after importing a certificate.
>
> *What is the solution?*
>
> The certificate should be stored in the database so that it is shared and
> a restart is not needed.
>
> *High-level design/UX decisions*
>
> 1) The SP UI will have a new text area to enter the certificate in PEM
> format.
>
> 2) The certificate will be stored in the SP_APP table. A new column will
> be added.
>
> *REASON*:
>
> Service provider --> certificate is a 1:1 relationship.
>
> 3) An interface will be introduced to abstract out the certificate
> handling of the SP. Two implementations will be there to support the
> current behavior and the proposed behavior.
>
> 4) Current behavior will be deprecated.
>
> 5) Choosing between the two implementations not explicit for the users, so
> a configuration will not be provided. If a certificate is not available in
> the database Identity Server will fall back to the current approach.
>
> *REASON*:
>
> 1. This feature is about changing an internal implementation. So the users
> should not worry about it.
>
>
>
> Please share your thoughts.
>
>
>
>
> --
> *Best Regards*
>
> *Rushmin Fernando*
> *Technical Lead*
>
> WSO2 Inc.  - Lean . Enterprise . Middleware
>
> mobile : +94775615183
>
>
>
> ___
> Architecture mailing list
> Architecture@wso2.org
> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
>
>


-- 

Hasanthi Dissanayake

Senior Software Engineer | WSO2

E: hasan...@wso2.com
M :0718407133| http://wso2.com 
___
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture

[Architecture] [Feature] Storing the application certificate in the database.

[Rushmin Fernando]

In the identity server, a service provider represents the application which
uses the Identity Server as an Identity Provider.

In some cases, Identity Server needs to validate the identity of the
application to make sure the authentication/authorization requests are
coming from the legitimate application.

*How is this done now?*

The application certificate should be imported to the keystore file and the
alias should be mentioned in the service provider so that the service
provider can validate the signature against the certificate identified by
that alias.

*Why is this needs to be improved?*

1) keystore file resides in the file system. Therefore in a clustered
deployment, either the certificate should be added to all the nodes or the
keystore file should be synced.

2) The server needs a restart after importing a certificate.

*What is the solution?*

The certificate should be stored in the database so that it is shared and a
restart is not needed.

*High-level design/UX decisions*

1) The SP UI will have a new text area to enter the certificate in PEM
format.

2) The certificate will be stored in the SP_APP table. A new column will be
added.

*REASON*:

Service provider --> certificate is a 1:1 relationship.

3) An interface will be introduced to abstract out the certificate handling
of the SP. Two implementations will be there to support the current
behavior and the proposed behavior.

4) Current behavior will be deprecated.

5) Choosing between the two implementations not explicit for the users, so
a configuration will not be provided. If a certificate is not available in
the database Identity Server will fall back to the current approach.

*REASON*:

1. This feature is about changing an internal implementation. So the users
should not worry about it.



Please share your thoughts.




-- 
*Best Regards*

*Rushmin Fernando*
*Technical Lead*

WSO2 Inc.  - Lean . Enterprise . Middleware

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