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 <[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. > > 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> > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Ruwan Abeykoon* *Associate Director/Architect**,* *WSO2, Inc. http://wso2.com <https://wso2.com/signature> * *lean.enterprise.middleware.*
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
