Hi all, I have completed basic flow with SAML2 artifact binding and sent a PR [1] <https://github.com/wso2-extensions/identity-inbound-auth-saml/pull/188>. Now we have the following points to decide on.
1. Issued SAML2 artifacts should have a shortest practical time limit which an artifact receiver can resolve it. We can define a property in identity.xml but need to define a default value for it. 2. Currently, I have defined the endpoint to resolve artifacts as "/ *samlartresolve*". We should decide on a suitable name if this one isn't. Please let me know your thoughts. Thanks, Vihanga. [1] - https://github.com/wso2-extensions/identity-inbound-auth-saml/pull/188 On Tue, Jul 10, 2018 at 6:14 PM Vihanga Liyanage <viha...@wso2.com> wrote: > 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 <malit...@wso2.com> > wrote: > >> >> >> 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 >> > > > -- > > Vihanga Liyanage > > Software Engineer | WS*O₂* Inc. > > M : +*94710124103* | http://wso2.com > > [image: http://wso2.com/signature] <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>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
