On Wed, Jul 4, 2018 at 9:13 PM, Vihanga Liyanage <viha...@wso2.com> wrote:
> Hi all, > > In the discussion we had today, a concern was raised about storing SAML > assertions in the database as it can become quite large. The alternatives > proposed are as follows. > > 1. Store any information we need to build the SAML assertion at > artifact resolution time and build it there. > > > - AFAIU, we need following data to be stored in the database to go > with this approach. > - Attributes in SAMLSSOAuthnReqDTO object. > > > - AuthenticatedUser > - NameIDFormat > - assertionConsumerURL > - idPInitSSOEnabled > - AuthnReq ID > - requestedRecipients list > - IdpAuthenticationContextProperties > - Issuer > - RequestedAttributes list > - IssuerWithDomain > - RequestedAudiences list > - SigningAlgorithmUri > - DigestAlgorithmUri > > > - Timestamp > - Session ID > > > 1. Build the assertion without signature data, which will reduce the > size. We can add the signature information at artifact resolution. > > > - For this approach, we need following data to be stored in the > database apart from the built assertion. > - Attributes in SAMLSSOAuthnReqDTO object. > > > - SigningAlgorithmUri > - DigestAlgorithmUri > - AuthenticatedUser > > Basically, algorithms can be identified by the SP. When the artifact resolving request comes if we can resolve the SP we could pick up the algorithms. I don't see a necessity of the authenticated user here, but the tenant domain. So we should be able to resolve the tenant domain from the artifact. > Currently, I have implemented to store and retrieve complete SAML > assertion as we decided earlier. AFAIU, option two would be better since > option one requires complex data to be stored in the DB. Please let me know > your thoughts on this. > As Ruwan had mentioned you will have to think of the significance of each property/param that you mentioned above to decide on the model. As I see we don't need to store all you mentioned above under (1) and build the assertion later. But I see authenticated subject, authentication request id as some significant attributes on any requirements to query the assertion. Moreover, at the time the artifact response goes to SP, the user is authenticated and the SAML assertion is the identity of that user. So I don't see there would be anything that will impact on the generated assertion when resolving the artifact and in returning the assertion. Thus, I would opt for option 2. Better if you can have a look at the Assertion query profile as well. We should be persisting the SAML assertion there as well or some structure to query the assertion. May be that implementation can be reused. @Omindu <omi...@wso2.com>, May be you can give more insight on query profile and see if we can relate with it's implementation in this context. > Also, do note following. > > - I couldn't find anything in the specifications that suggest or > oppose doing any of these. (Please correct me if I'm wrong) Therefore, we > have the freedom do what we see as best. > - We don't execute search functions in the DB using assertions. > > Best Regards, > Vihanga. > > On Tue, Jul 3, 2018 at 1:48 PM Maduranga Siriwardena <madura...@wso2.com> > wrote: > >> Databases can handle large text fields. Column type depends on the >> database. For example [1] shows few MySql column types that can handle >> large texts. >> >> And in the same time there are some database column types that can handle >> xml etc. You will need to do some research to to find suitable column type >> for your requirement. >> >> [1] https://stackoverflow.com/questions/6766781/maximum- >> length-for-mysql-type-text >> >> Thanks, >> >> On Tue, Jul 3, 2018 at 12:26 PM Vihanga Liyanage <viha...@wso2.com> >> wrote: >> >>> Hi Farasath, >>> >>>> >>>> SAML Assertion size is going to depend with the number of requested >>>> claims, signing, encryption etc. How are we planning to handle this >>>> ? >>>> >>> >>> That is a valid question! The initial value, 4096 was used in the >>> IDN_SAML2_ASSERTION_STORE table. But with my implementation, later I found >>> out that it's not enough and used 5120 for now. Is there a maximum size >>> that we can decide on? >>> >>>> >>>> >>>> >>> >> >> -- >> Maduranga Siriwardena >> Senior Software Engineer >> WSO2 Inc; http://wso2.com/ >> >> Email: madura...@wso2.com >> Mobile: +94718990591 >> Blog: *https://madurangasiriwardena.wordpress.com/ >> <https://madurangasiriwardena.wordpress.com/>* >> <http://wso2.com/signature> >> > > > -- > > Vihanga Liyanage > > Software Engineer | WS*O₂* Inc. > > M : +*94710124103* | http://wso2.com > > [image: http://wso2.com/signature] <http://wso2.com/signature> > Thanks, Malithi. -- *Malithi Edirisinghe* Associate Technical Lead WSO2 Inc. Mobile : +94 (0) 718176807 malit...@wso2.com
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
