Shibboleth Developers

["Howard Gilbert" <>]

> I went to the Protocols and Profiles document to back up my intuition
> that the Shibboleth service provider doesn't really need to know about
> anything until the user has been authenticated.  The first obvious
> mismatch is with the sequence diagram in the architectural overview; I'd
> see what we're doing as replacing steps 1 and 2 with a direct
> interaction between the user agent and the WAYF.
> 
> Step 1 in this diagram is described as a required interaction.  

The term "Service Provider" is actually quite vague. It could cover
everything at the site that is offering the service. It certainly includes
the Authentication Assertion Consumer Service (formerly known as the SHIRE)
and the Attribute Assertion Consumer Service (formerly know as the SHAR),
and the Resource itself (which may be managed by an Apache mod, ISAPI
Filter, Servlet Filter, or by code you wrote yourself as part of an
application). It also includes two aspects of the SHAR, one which holds
attributes (in memory, in cache, in database, wherever), which feeds the
attributes on request to the Resource Manager. All these things are part of
any implementation, but they aren't part of any standard because the
internal attribute housekeeping isn't part of the protocol.

The architecture concentrates on the two Assertion Consumers. This is wire
stream protocol between hosts (and sites). It cannot describe the Resource
manager because I can write one myself in any programming language and any
server environment. Nor is there any requirement that the Resource be
managed by code that runs on only one machine. So that initial Form can,
within the scope of the architecture, be regarded as part of the Resource
manager and, therefore, part of the Service Provider.

In other words, your Form is part of the Service Provider in Step 1.

That said, we do need to clean up some confusion, particularly in the
configuration file. The Resource is managed by a Web Server, and the POST of
Authentication data is received by a Web Server, and so typically the two
things were handled by different aspects of the same module. However,
configuration of the two then got merged or at least confused. 

You sort of see this when your Form includes a "providerID" field. The
"shire" you might just know as a well known service URL, and the "target" is
the URL of the Resource data that you are managing. However, you don't just
trip over "providerId". It has to match some magic name configured inside
the Shibboleth configuration data. Since most of the time the Resource
manager code that is filling in this stuff is another aspect of the same
module that does the SHIRE function, coming up with magic strings from the
configuration file isn't an issue. The documentation isn't as clear about
how you would write your own arm's length Resource Manager, and that may be
the source of confusion here where you don't realize that your Form is,
plausibly, part of the Resource Management function.