Shibboleth Developers

["Tom Scavo" <>]

I've extended resolvertest to output complete attribute assertions.
It seems reasonable that resolvertest could be further extended to
output authn responses complete with attributes.  Such a tool suggests
the following test scenario for 2.0:

1. install J2SE and ant
2. install IdP
3a. run shibtest-idp
3b. if satisfied, goto step 4
3c. configure IdP
3d. goto step 3a
4. install Java SP
5a. run shibtest
5b. if satisfied, goto step 6
5c. configure Java SP
5d. goto step 5a
6. install tomcat
7. join testshib.org
etc.

Step 3a is the "instant gratification step".  The command-line tool
shibtest-idp is the logical conclusion of resolvertest.  It takes an
authn request as input and gives an authn response (with attributes)
as output.  As used at step 3a, shibtest-idp simply exercises the IdP
config for a given user and relying party.

Step 5a is the "continued gratification step".  The tool shibtest at
step 5a is the composition of shibtest-idp and another tool called
shibtest-sp.  The latter takes an authn response as input and gives
the corresponding SSO assertion(s) as output.  Used in this way,
shibtest effectively simulates IdP-initiated SSO.

To simulate SP-initiated SSO, an alternate invocation of shibtest-sp
is used at step 5a.  In this case, shibtest reduces to the following
pipe (roughly):

$ shibtest-sp --request <args> | shibtest-idp <args> | shibtest-sp
--response <args>

This command outputs the SSO assertion(s) issued by the IdP as
consumed by the SP.

Note that tomcat isn't required until step 6.  Installation of apache
and the C++ SP is even further down the line.  This significantly
lowers the bar with respect to required technology.  Does this seem
like a reasonable strategy?

Tom