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] [1] - "Invitation: [Architecture Review] - SAML Artifact Binding" @ engineering On Fri, Jun 22, 2018 at 4:38 PM Vihanga Liyanage <[email protected]> wrote: > [+ Dev] > > On Fri, Jun 22, 2018 at 3:23 PM Vihanga Liyanage <[email protected]> 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 <[email protected]> >> 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" @ >>> [email protected] >>> [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>
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
