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 <[email protected]> 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 <[email protected]> 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 <[email protected]> >> wrote: >> >>> >>> >>> On Mon, Jan 8, 2018 at 3:19 AM, Shazni Nazeer <[email protected]> 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 <[email protected]> wrote: >>>> >>>>> Thanks for the explanation Rushmin. Yeah, it makes sense. +1 >>>>> >>>>> >>>>> Thanks >>>>> Godwin >>>>> >>>>> On Fri, Jan 5, 2018 at 3:30 PM, Rushmin Fernando <[email protected]> >>>>> 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 <[email protected]> >>>>>> 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 <[email protected]> >>>>>>> wrote: >>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> On Fri, Jan 5, 2018 at 11:55 AM, Isura Karunaratne <[email protected]> >>>>>>>> wrote: >>>>>>>> >>>>>>>>> Hi Rushmin, >>>>>>>>> >>>>>>>>> On Fri, Jan 5, 2018 at 11:50 AM, Hasanthi Purnima Dissanayake < >>>>>>>>> [email protected]> 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 < >>>>>>>>>> [email protected]> 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. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>>>>>>>> >>>>>>>>>>> mobile : +94775615183 >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>>> _______________________________________________ >>>>>>>>>>> Architecture mailing list >>>>>>>>>>> [email protected] >>>>>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>>>>> >>>>>>>>>>> >>>>>>>>>> >>>>>>>>>> >>>>>>>>>> -- >>>>>>>>>> >>>>>>>>>> Hasanthi Dissanayake >>>>>>>>>> >>>>>>>>>> Senior Software Engineer | WSO2 >>>>>>>>>> >>>>>>>>>> E: [email protected] >>>>>>>>>> M :0718407133| http://wso2.com <http://wso2.com/> >>>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> -- >>>>>>>>> >>>>>>>>> *Isura Dilhara Karunaratne* >>>>>>>>> Associate Technical Lead | WSO2 >>>>>>>>> Email: [email protected] >>>>>>>>> Mob : +94 772 254 810 <+94%2077%20225%204810> >>>>>>>>> Blog : http://isurad.blogspot.com/ >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> -- >>>>>>>> *Best Regards* >>>>>>>> >>>>>>>> *Rushmin Fernando* >>>>>>>> *Technical Lead* >>>>>>>> >>>>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>>>>> >>>>>>>> mobile : +94775615183 >>>>>>>> >>>>>>>> >>>>>>>> >>>>>>>> _______________________________________________ >>>>>>>> Architecture mailing list >>>>>>>> [email protected] >>>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>>> >>>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Godwin Amila Shrimal* >>>>>>> Associate Technical Lead >>>>>>> WSO2 Inc.; http://wso2.com >>>>>>> lean.enterprise.middleware >>>>>>> >>>>>>> mobile: *+94772264165* >>>>>>> linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/ >>>>>>> <https://www.linkedin.com/in/godwin-amila-2ba26844/>* >>>>>>> twitter: https://twitter.com/godwinamila >>>>>>> <http://wso2.com/signature> >>>>>>> >>>>>>> _______________________________________________ >>>>>>> Architecture mailing list >>>>>>> [email protected] >>>>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> *Best Regards* >>>>>> >>>>>> *Rushmin Fernando* >>>>>> *Technical Lead* >>>>>> >>>>>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>>>>> >>>>>> mobile : +94775615183 >>>>>> >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Godwin Amila Shrimal* >>>>> Associate Technical Lead >>>>> WSO2 Inc.; http://wso2.com >>>>> lean.enterprise.middleware >>>>> >>>>> mobile: *+94772264165* >>>>> linkedin: *https://www.linkedin.com/in/godwin-amila-2ba26844/ >>>>> <https://www.linkedin.com/in/godwin-amila-2ba26844/>* >>>>> twitter: https://twitter.com/godwinamila >>>>> <http://wso2.com/signature> >>>>> >>>>> _______________________________________________ >>>>> Architecture mailing list >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Shazni Nazeer >>>> >>>> Mob : +94 777737331 >>>> LinkedIn : http://lk.linkedin.com/in/shazninazeer >>>> >>>> Blogs : >>>> >>>> https://medium.com/@mshazninazeer >>>> http://shazninazeer.blogspot.com >>>> >>>> <http://wso2.com/signature> >>>> >>> >>> >>> >>> -- >>> *Best Regards* >>> >>> *Rushmin Fernando* >>> *Technical Lead* >>> >>> WSO2 Inc. <http://wso2.com/> - Lean . Enterprise . Middleware >>> >>> mobile : +94775615183 >>> >>> >>> >> >> >> -- >> Shazni Nazeer >> >> Mob : +94 777737331 >> LinkedIn : http://lk.linkedin.com/in/shazninazeer >> >> Blogs : >> >> https://medium.com/@mshazninazeer >> http://shazninazeer.blogspot.com >> >> <http://wso2.com/signature> >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > Inosh Perera > Senior Software Engineer, WSO2 Inc. > Tel: 077813 7285, 0785293686 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Kamidu Sachith Punchihewa *Senior Software Engineer* WSO2, Inc. lean . enterprise . middleware Mobile : +94 (0) 770566749 <%2B94%20%280%29%20773%20451194> Disclaimer: This communication may contain privileged or other confidential information and is intended exclusively for the addressee/s. If you are not the intended recipient/s, or believe that you may have received this communication in error, please reply to the sender indicating that fact and delete the copy you received and in addition, you should not print, copy, retransmit, disseminate, or otherwise use the information contained in this communication. Internet communications cannot be guaranteed to be timely, secure, error or virus-free. The sender does not accept liability for any errors or omissions.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
