Shibboleth Developers

["Howard Gilbert" <>]

First, since it was easier to write code than to discuss it, I added code to the Java Service Provider and Resource Filter to exactly duplicate the SHIRE logic of the C++ filters. The SHIRE URL can now be in the Resource directory, and just as with C++ the POST data is tunneled over to the main shibboleth process where it is processed and a session is created. The SessionId is returned from this "RPC" call and can be used to fetch attributes.

 

Of course, you still can create configurations where the SHIRE URL appears to be part of the /shibboleth directory instead of appearing as part of the Resource directory. Its a choice.

 

I have two problems that I am trying to solve. One comes from the CAS-Shibboleth paper where I was trying to figure out how to get the SHIRE to return through CAS before going to the Resource Manager.

The other comes from a complaint from Scott that, when the SHIRE is separate from the filter (if it is a Servlet in the /shibboleth application), he is unhappy about any technique that adds data to the original Resource query string.

 

To solve both problems, one can (and this would be an option configured in the Resource Manager Filter) encode the target= string so that the Browser makes one (or more) intermediate stop between the SHIRE and the resource.

 

First, take the original Resource URL, encode it, and make it the value of a target=xxxx parameter in another URL. Currently we do this and put the target parameter in the URL that redirects the Browser to the WAYF. On the way back, the SHIRE finds the parameter, decodes it, and uses the value to redirect the Browser back to the Resource.

 

However, in this trick the target=xxxx that points to the resource becomes, instead, part of a URL that points to the CAS server, or to an intermediate processing step in the Filter. We take this intermediate stop URL that contains its own target= parameter, URLencode it, and make the resulting string the target=yyyy parameter of the WAYF redirect.

 

The SHIRE does exactly what it did before. It gets the POST, processes it, and redirects to its "target=" string. In this case, however, the Redirect goes to CAS or to an intermediate processing step in the Resource Filter. In either case, CAS or the Filter gets the session info, fetches the attributes, and stores them in the CAS cache or HttpSession. Now CAS or the Filter unwraps the internally nested second level target=xxxx parameter in their URL and tells the Browser to do one more redirect.

 

This last redirect may send the Browser to a CAS Filter protected application, which then uses CAS protocol to fetch the attributes. Alternately, it can send the browser back to the original Resource URL, but this time with a cookie, session, and attributes already set up and a clean original URL with nothing appended.

 

Recap: The URL in the WAYF/SHIRE target= parameter is a URLencoded string that contains a URL. The inner URL contains a target= parameter that contains a URLencoded string that contains the Resource URL. The WAYF, HS, and SHIRE are unmodified and continue to do what they have always done. The change occurs entirely within the Resource Manager.

 

Potentially there is one change, but it doesn't affect any part of the published protocol. If you want to know the URL of the original resource, to do some form of RequestMap processing, then the code that extracts and decodes the URL from the target= parameter has to check for nested targets and do a second parse-decode. Otherwise it will confuse the URL of CAS with the URL of the Resource. I can write a method that does this automatically. Since this is new function for new configurations that don't exist yet, no existing code has to change and new code can use the common method.

 

Encoding an already encoded string adds some processing and makes the string longer and uglier, but I don't think this is an important problem. There is an extra Redirect, but we have so many Redirects in the current path I have lost count. Is this a "cute" (bad) or an "elegant" (good) solution?