<html>

  <head>

    <meta content="text/html; charset=windows-1252"

      http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#000000">

    <br>

    <br>

    <div class="moz-cite-prefix">On 2/5/16 4:49 PM, Cantor, Scott wrote:<br>

    </div>

    <blockquote

cite="mid:9846A6064BD102419D06814DD0D78DE112826BA5@CIO-TNC-D2MBX02.osuad.osu.edu"

      type="cite">

      <blockquote type="cite">

        <pre wrap="">This is *not* a valid ECP SOAP request. It's completely missing the

<paos:Request> and <ecp:Request> SOAP headers.

</pre>

      </blockquote>

      <pre wrap="">

Very true, but I'm mostly just concerned about adequate logging for errors right now. ;-)

Clearly whatever this script/client is, it's not even close to usable though.

</pre>

    </blockquote>

    <br>

    Well, I vaguely knew this from seeing this in the AWS docs before,

    just skimmed again:  This AWS flow is not actually technically the

    SAML 2 ECP profile, as in: client does PAOS to SP, gets back the

    AuthnRequest and so on.  It's not any official SAML flow or profile,

    AFAIK.  It's I believe something they (Amazon) just made up.  Sort

    of like "unsolicited ECP" I guess.  Client contacts IdP first, gets

    SAML Response with Assertion, then exchanges that at an AWS notion

    of a Security Token Service to get AWS creds. It's not WS-Trust,

    it's their own RESTful API.  I'm not an expert.  But the main flow

    is detailed here complete with flow diagram [1], and the way you use

    the response/assertion at their "STS" is here. [2]<br>

    <br>

    As far as the client <-> IdP interaction goes, AFAIK they're

    expecting the customer to solve that or make something up.  Don't

    think it's specified.  <br>

    <br>

    All this is clearly problematic, but the issue here really isn't

    necessarily with this guy's script, but rather with the AWS service

    and requirements itself.   I think the script just tries to do

    something to make this work with an existing SAML IdP, as crazy or

    invalid as necessary.  For example the binding it's sending is

    bogus, since it's not going to do that anyway, as would be the AWS

    SP metadata.<br>

    <br>

    I am possibly going to be lucky enough to learn about all this for

    real, as my school has "cloud" on the brain and is getting heavily

    into AWS.  Oh joy.<br>

    <br>

    <br>

    <br>

    [1]

<a class="moz-txt-link-freetext" href="http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html">http://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_providers_saml.html</a><br>

    <br>

    [2]

<a class="moz-txt-link-freetext" href="http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html">http://docs.aws.amazon.com/STS/latest/APIReference/API_AssumeRoleWithSAML.html</a><br>

    <br>

  </body>

</html>