Hi all, We had a conflict in the last review with the SAML assertion query profile [1] <https://docs.wso2.com/display/IS530/Querying+SAML+Assertions> implementation. *What should happen when an artifact is issued to an SP and it's not yet resolved? Should the app be able to query the assertion according to assertion query profile?* I couldn't find anything in the two specifications that relate to this situation. I've tried to see how Forgerock implementation works, but that failed as well. Since we're on a tight schedule, I'm going with below solution.
When artifact binding is enabled, I will check for query profile enablement as well after building the artifact. If yes, then I'll call the *ExtendedDefaultAssertionBuilder.buildAssertion() [2] <https://github.com/wso2-extensions/identity-inbound-auth-saml/blob/d470e52885e75e10352670f53670945c2a793947/components/org.wso2.carbon.identity.sso.saml/src/main/java/org/wso2/carbon/identity/sso/saml/builders/assertion/ExtendedDefaultAssertionBuilder.java#L70> *method, which will build and save the assertion in the IDN_SAML2_ASSERTION_STORE table. I'll save the ID of this built SAML assertion in a new column of the IDN_SAML2_ARTIFACT_STORE table. When resolving the issued artifact, current implementation builds the assertion using the data stored in the IDN_SAML2_ARTIFACT_STORE table. Instead, if query profile is enabled, I'll get the assertion from the IDN_SAML2_ASSERTION_STORE using the SAML ID. Please do let me know your concerns. Thanks, Vihanga. [1] - https://docs.wso2.com/display/IS530/Querying+SAML+Assertions [2] - https://github.com/wso2-extensions/identity-inbound-auth-saml/blob/d470e52885e75e10352670f53670945c2a793947/components/org.wso2.carbon.identity.sso.saml/src/main/java/org/wso2/carbon/identity/sso/saml/builders/assertion/ExtendedDefaultAssertionBuilder.java#L70 On Thu, Jul 12, 2018 at 10:40 AM Vihanga Liyanage <[email protected]> wrote: > 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 <[email protected]> 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 <[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> >> > > > -- > > 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 [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
