Shibboleth Developers

[Derek Atkins <>]

"Scott Cantor" 
<>
 writes:

>> True.  Are you suggesting that we store a callback state object in
>> some special data of the apache request_rec structure?
>
> No, in the callback object you were creating. I'm just noting that I added
> some state to the SHIRE object so that I could cache some things like
> manufacturing the SHIRE location, and we could just add the Apache/IIS
> "state" structure your callback was storing to what I had, and it seems like
> it's useful to push the two together.

Uh, I think we may be talking past each other.  Let me try again.

I'm creating an interface for webserver-specific callbacks and a few
"static" functions that are web-server agnostic.  The static functions do
all the hard work -- the web server calls them in the various
hook(s) for processing the request.

Each web server module implements a subclass of the callback interface
and creates an instance of this subclass for each request.  Obviously
some amount of state information can go into this instance, but this
instance is implementation-dependent.  In other words, if there is
state information we want to access/change from the agnostic part we
need to include that API in the interface class.

In the apache case, I want to maintain the same subclass instance
through the whole life of the request, which would imply that we store
a pointer to it in the request_rec -- but that only works in apache2.
Otherwise, we need to push state back into the request_rec so it's
maintained between the check_user() and check_auth() apache methods.

Another thing to point out is that the current SHIRE (and RM)
implementations require knowledge of the current application.  I'm
trying to remove that information from the API presented to the
webserver module implementation because that part of the processing
really is agnostic.  Why duplicate the "get application from url" code
in each module when you can just pass the URL and let the agnostic
code compute the application?

But I do see your point in that I could change the SHIRE api to take a
callback instead of an application in order to merge these functions
into one object.  See the attached API for what I think you mean.

>> The only two data I think I need access to (besides the htaccess) is
>> the key used to detect whether to run the shib_post_handler on apache2
>> and the authtype for basicHijack.  I can probably work around these
>> two if I think about it harder.
>
> You could just abstract some of the auth type handling so that it can be
> stubbed out on IIS, since there's no real equivalent.

Yea, I just need to figure out what to do about that, and what the API
needs to look like.  I'm thinking that I may need to play with this a
bit to get it working, which may mean prototyping an apache
implementation and then making sure I can get an IIS implementation to
fit in as well.

I suppose I could add a get/setAuthType() method -- and I may be able
to handle the shib_post_handler issue purely inside the apache
implementation.  I think I'm going to have to experiment a bit, or at
least answer that once I get to the actual implementation.

>> Hmm, so basically you think something like this:
>> 
>>   void* sendPage(String msg, pair<String,String> headers[] = 
>> null, int code = 200);
>
> Yeah, that's roughly similar to the functions I created in the IIS module.

Ok.  I'm trying to minimize the function(s) that the module needs to
implement.  So if I can reduce the subclass implementation to a single
API (instead of two or three) that's ideal.  That's why I'd like to
use optional arguments here.  :)

> -- Scott

-derek


class ShibRequestParams {
public:
  ShibRequestParams() {}
  ~ShibRequestParams() {}
  String url;
  String method;
  String content_type;
  String remote_addr;
  int total_bytes;
};

class ShibWSCallbacks {
public:
  virtual ~ShibWSCallbacks() {}

  // These are defined here so the module does not need to specifically
  // depend on log4cpp.  We could use log4cpp::Priority::PriorityLevel
  // but this is just as easy, IMHO.  It's just a case statement in the
  // implementation to handle the event level.
  enum ShibLogLevel {
    LogLevelDebug,
    LogLevelInfo,
    LogLevelWarn,
    LogLevelError
  };

  // Send a message to the Webserver log
  virtual void log(ShibLogLevel level, String msg) = 0;

  // Get/Set cookie for this connection
  virtual String getCookie(String name) = 0;
  virtual String setCookie(String name, String value) = 0;

  // Get the request parameters
  virtual const ShibRequestParams& getRequestParams(void) = 0;

  // Get the request POST data
  virtual String getPostData(void) = 0;

  // Not sure if I need these, but I might for something like Apache
  // in order to "fix" the auth type in the case of basicHijack.  In
  // particular we need to maintain some state between the different
  // APIs to know whether or not to proceed with shib processing.
  virtual String getAuthType(void) = 0;
  virtual void setAuthType(String) = 0;

  // Note: we probably need some way to acquire the htaccess-equivalent
  // information here.
  virtual HTAccessInfo& getAccessInfo(void) = 0;

  // Finish the shib session with some page result or a redirect.
  virtual void* sendPage(String msg, pair<String,String> headers[] = null,
                         int code = 200) = 0;
  virtual void* sendRedirect(String url) = 0;

  // These functions implement the server-agnostic shibboleth engine
  // Alternatively, these functions can be moved into the SHIRE and RM
  // classes.
  static void* doCheckAuthN(ShibWSCallbacks &cbs);
  static void* doHandlePOST(ShibWSCallbacks &cbs);

  static void* doCheckAuthZ(ShibWSCallbacks &cbs);
};


// This is how I think it would look if we moved the agnostic
// implementation into the SHIRE and RM classes, but it just seems so
// klunky to do it this way and IMHO it doesn't seem to really help
// anything.

class SHIRE {
  SHIRE(ShibWSCallbacks &cbs);
  ...

  void* doCheckAuthN();
  void* doHandlePOST();
}

class RM {
  RM(ShibWSCallbacks &cbs);
  ...

  void* doCheckAuthZ();
}

-- 
       Derek Atkins, SB '93 MIT EE, SM '95 MIT Media Laboratory
       Member, MIT Student Information Processing Board  (SIPB)
       URL: http://web.mit.edu/warlord/    PP-ASEL-IA     N1NWH
       

                        PGP key available