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
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
