On Mon, Jul 2, 2018 at 2:48 PM, Vihanga Liyanage <viha...@wso2.com> wrote:
> Hi all, > > As for the discussion we had earlier [1], here attached the initial table > design to store the SAML assertions against the artifact ID. Please let me > know your concerns regarding this or anything discussed earlier. > > [image: image.png] > SAML Assertion size is going to depend with the number of requested claims, signing, encryption etc. How are we planning to handle this? > > [1] - "Invitation: [Architecture Review] - SAML Artifact Binding" @ > engineering > > On Fri, Jun 22, 2018 at 4:38 PM Vihanga Liyanage <viha...@wso2.com> wrote: > >> [+ Dev] >> >> On Fri, Jun 22, 2018 at 3:23 PM Vihanga Liyanage <viha...@wso2.com> >> wrote: >> >>> Hi all, >>> >>> As I'm going through the specifications, I came across following >>> problems. >>> >>> - The above diagram shows Login Response binding with SAML art. >>> There are other aspects of this as well such as Login Request Binding, >>> Logout Request Binding, etc. Below diagram shows both login request and >>> response bound with SAML art. >>> >>> [image: image.png] >>> Question is, which should we do first. I think login >>> response binding is better, to begin with. >>> >>> - IDP has to store a reference to the artifact so that it can >>> respond with the SAML assertion to the SP. We can either generate the >>> assertion and store it completely in the database and send that, or we >>> can >>> generate and send the assertion once the artifact is received. What >>> should >>> be the best method? >>> - Should we keep a status about the artifact and assertion in our >>> DB? If yes, what are the use cases? >>> - What should happen if an artifact is sent again by someone after >>> the assertion is issued? The spec says the following but I didn't see any >>> specific instruction on what to do. >>> - *"It is RECOMMENDED that artifact receivers also enforce a >>> single-use semantic on the artifact values they receive, to prevent an >>> attacker from interfering with the resolution of an artifact by a user >>> agent and then re-submitting it to the artifact receiver. If an >>> attempt to >>> resolve an artifact does not complete successfully, the artifact >>> SHOULD be >>> placed into a blocked artifact list for a period of time that exceeds >>> a >>> reasonable acceptance period during which the artifact issuer would >>> resolve >>> the artifact."* >>> >>> Please let me know your thoughts on the above. >>> >>> Regards, >>> Vihanga. >>> >>> On Wed, Jun 20, 2018 at 10:28 AM Vihanga Liyanage <viha...@wso2.com> >>> wrote: >>> >>>> Hi all, >>>> >>>> I've started working on the server-side implementation of SAML Artifact >>>> Binding. The basic idea is as follows. >>>> >>>> When authentication is done via SAML, SAML assertion is sent to the >>>> user agent (browser) as a direct response from the IDP. One disadvantage of >>>> this method is the possibility of communication messages being intersepted >>>> at the browser. Also, there could be limitations on browsers such as limits >>>> on query string / POST payload sizes, no support for JavaScript, etc. To >>>> overcome these problems, SAML Artifact Binding has been introduced. >>>> >>>> When the user is authenticated, the IDP responds with a key known as >>>> SAMLart, which will be then sent to the service provider by the browser. >>>> Then the SP uses this key to request the actual SAML assertion from the IDP >>>> via a back channel call. This method reduces the use of browsers compared >>>> to the old method. Below diagram shows the request flow with SAML Artifact >>>> Binding. >>>> >>>> [image: image.png] >>>> >>>> Currently the client side implementations have been completed and >>>> discussed here [1]. The goal of this project is to implement the necessary >>>> backend components following the official SAML specification [2] >>>> <https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf> >>>> . >>>> >>>> I highly appriciate your valuable concerns and input on this. >>>> >>>> Best regards, >>>> Vihanga. >>>> >>>> [1] - "[Architecture] [IAM] SAML Artifact Binding" @ >>>> architecture@wso2.org >>>> [2] - https://www.oasis-open.org/committees/download.php/35387/ >>>> sstc-saml-bindings-errata-2.0-wd-05-diff.pdf >>>> <https://www.google.com/url?q=https://www.oasis-open.org/committees/download.php/35387/sstc-saml-bindings-errata-2.0-wd-05-diff.pdf&sa=D&source=hangouts&ust=1529490475881000&usg=AFQjCNG3_d5jo1kSGGuO9_TMVz2oNTswag> >>>> -- >>>> >>>> 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> > > -- > You received this message because you are subscribed to the Google Groups > "WSO2 Engineering Group" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to engineering-group+unsubscr...@wso2.com. > For more options, visit https://groups.google.com/a/wso2.com/d/optout. > -- Farasath Ahamed Senior Software Engineer, WSO2 Inc.; http://wso2.com Mobile: +94777603866 Blog: blog.farazath.com Twitter: @farazath619 <https://twitter.com/farazath619> <http://wso2.com/signature>
_______________________________________________ Architecture mailing list Architecture@wso2.org https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
