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>
_______________________________________________
Architecture mailing list
Architecture@wso2.org
https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
