<HTML dir=ltr><HEAD></HEAD>
<BODY>
<DIV id=idOWAReplyText79515 dir=ltr>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2>Wonderful that there is an easy way! </FONT><FONT face=Arial size=2>I just read the code, fiddled step by step till it did something sensible. At least I now understand handler mode much better, so SAML/ShibSP itself becomes service operating on its own host supporting a cluster of webapps.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>Q: is there any way via query-string to populate the IDPList with >1 entry?</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>In terms of my own ECP client (for post WAP1 era usages) there is only 1 agenda with 3 components, which I trust can merge with other folks efforts:-</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>1. Nominally, the proxy will be the generator of the AuthnResponse. How it generates/signs this blob is a blackbox issue for the SP.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>2. In fact, my own proxy will leverage a data server (from a realty open standard peculiar to US Realty) that looks and functions a bit like a SemWeb SPARQL server, listening for data queries on some or other URI binding.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>3. The data servers already operate their own secure chaining model. Thus, the ECP proxy can be seen as an aggregator of SAML assertions that said chaining parties provide, and will act as the ultimate signer of the AuthnResponse.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>From the std, the ECP proxy is obligated to restrict which SAML assertions it puts into a Response, and from which (single) source.</FONT></DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2>In a second phase, I will then play with ECP/SAML2 proxying in its own right, trying to take from the WAP1 roaming world whats useful to carry forward to today.</FONT></DIV>
<DIV dir=ltr><FONT face="Times New Roman" size=3></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial size=2></FONT> </DIV>
<DIV dir=ltr><FONT face=Arial color=#000000 size=2></FONT> </DIV></DIV>
<DIV id=idSignature77793>
<DIV><FONT face=Arial color=#000000 size=2><SPAN style="FONT-SIZE: 7.5pt">_________________________<BR></SPAN><B>Peter Williams<BR></B><SPAN style="FONT-SIZE: 7.5pt">Chief Information Security Officer<BR>Mobile (805) 416-6305</SPAN></FONT></DIV></DIV>
<DIV dir=ltr><BR>
<HR tabIndex=-1>
<FONT face=Tahoma size=2><B>From:</B> Scott Cantor<BR><B>Sent:</B> Mon 4/28/2008 12:10 PM<BR><B>To:</B> 'Peter Williams'; wsf-dev@lists.openliberty.org<BR><B>Subject:</B> RE: [wsf-dev] ECP plugin build/execute feedback<BR></FONT><BR></DIV>
<DIV><PRE style="WORD-WRAP: break-word">> To allow IIS7 (via the shib_isapi handler) to invoke the NativeSP in
> "handler" mode (so Shib2 act as a layer 5 protocol engine, rather than
web-
> session middleware) and then support a trial generting a SAMLRequest using
> ECP and PAOS, I did the following
None of that is necessary, Shibboleth is easily able to issue requests with
a simple get to /Shibboleth.sso/Login.
> 4. Invoke trial usin tool like curl(1) ...using GET to induce protocol
run,
> where providerId parameter is demonstrably set to "none" to showcase the
ECP
> scenario.
That means you want to use the IdP named "none". You want to omit it
altogether.
(The I2 lists are down, that's why your message hasn't made it yet. If
you're having problems with the SP that required you to change the code,
just ask directly until the list is up.)
-- Scott
</PRE></DIV></BODY></HTML>