Shibboleth Developers

[Tom Scavo <>]

Hi Howard,

I'm not sure what the proposals are, but here are some thoughts that
come to mind:

- The SSO service at the IdP may issue a response that results in an
HTTP POST (as you observed) or it may issue a redirect with an
artifact attached.

- The SP indicates its preference (browser/post or browser/artifact)
with an appropriate parameter:

shire=https://sp.com/shibboleth/SSO/POST

or

shire=https://sp.com/shibboleth/SSO/Artifact

- Both URIs may be encoded as metadata:

  <md:SPSSODescriptor
    protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
    ...
    <md:AssertionConsumerService index="1"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-POST"
      Location="https://sp.com/shibboleth/SSO/POST"/>
    <md:AssertionConsumerService isDefault="true" index="0"
      Binding="urn:oasis:names:tc:SAML:2.0:bindings:HTTP-Artifact"
      Location="https://sp.com/shibboleth/SSO/Artifact"/>
  </md:SPSSODescriptor>

- As you probably know, the web server (Apache) and the app server
(Tomcat) may be configured so that all requests go through the web
server to get to the app server.  In that case, can't you continue to
use existing Apache modules and thereby avoid application-level J2EE
filters?

Just some thoughts.  Hope this helps.  Tom

On Fri, 5 Nov 2004 11:52:57 -0500, Howard Gilbert
<>
 wrote:
> 
> 
> 
> The C++ and Java Service Providers have potential differences in their
> configuration philosophy. Currently the same configuration file generates
> the same result thanks to careful programming.
> 
>  
> 
> Everything you need is already part of the protocol and configuration
> schemas. I would argue that the current C++ code and the resulting
> configuration examples assume some redundancy in items that need not be
> redundant. There are some interesting possibilities here if we are willing
> to draw some distinctions. Or maybe not.
> 
>  
> 
> I have written a rather extensive discussion of the interplay between
> parameters, and lay some proposals on the table for a broader
> interpretation. See
> 
>  
> 
> http://tp.its.yale.edu/shib/tiki-index.php?page=ShireUrl
> 
>