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 <[email protected]> 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 <[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.* > > -- 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
