Hi all, With the discussion we had today, we have decided to go with below database structure.
IDN_SAML2_ARTIFACT_STORE PK ID INT NOT NULL SOURCE_ID BLOB NOT NULL MESSAGE_HANDLER BLOB NOT NULL AUTHN_REQ_DTO BLOB NOT NULL SESSION_ID VARCHAR(255) NOT NULL INTI_TIMESTAMP DATETIME NOT NULL EXP_TIMESTAMP DATETIME NOT NULL We'll build the SAML assertion as well as the response object at artifact resolution time. Please let me know your concerns on this. Best regards, Vihanga. On Thu, Jul 5, 2018 at 8:12 AM Malithi Edirisinghe <[email protected]> wrote: > > > On Wed, Jul 4, 2018 at 9:13 PM, Vihanga Liyanage <[email protected]> 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 <[email protected]>, > 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 <[email protected]> >> 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 <[email protected]> >>> 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: [email protected] >>> 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 > [email protected] > -- Vihanga Liyanage Software Engineer | WS*O₂* Inc. M : +*94710124103* | http://wso2.com [image: http://wso2.com/signature] <http://wso2.com/signature>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
