Hi all, I have completed the implementations of the feature and now in the process of writing an integration test suit. While doing that I faced a few issues.
The plan is to use the new IS samples in here [1] <https://github.com/wso2/samples-is/tree/master/saml2-sso-sample/components/SAML2/saml2-web-app-dispatch>, since we no longer encouraged to use the Travelocity app. But this new sample app seems to have issues when running on Tomcat 7 and I think this is the cause for the issues I'm having with tests. Is it possible to upgrade the Tomcat version from 7 to 8? If so what would be the procedure? Your valuable ideas are highly appreciated. Regards, Vihanga. [1] - https://github.com/wso2/samples-is/tree/master/saml2-sso-sample/components/SAML2/saml2-web-app-dispatch On Mon, Jul 16, 2018 at 6:24 PM Vihanga Liyanage <[email protected]> wrote: > 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> > -- 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
