Shibboleth Developers

[Derek Atkins <>]

"Scott Cantor" 
<>
 writes:

>> Enclosed is the draft API.  Scott (et al) could you let me know
>> what you think?  What am I missing?  Good? Bad? Indifferent?
>
> Some early thoughts...

Thanks..

> Design-wise, can we merge this into the existing SHIRE and RM classes
> somehow and have some of the methods common to both implementations (i.e.
> the ones that don't care about the web server) and others that are specific
> to each. I think that's where you're headed with the "doCheck..." stuff, but
> I wasn't sure.

Well, mostly I was trying to mirror the three Apache calls.
doCheckAuthN checks if this is a shibbolized URL and if so makes sure
we have a session.  doCheckAuthZ performs the required authorization
checks for the resource.  The last API to process the POST is fairly
self-explanatory.

I suppose we could try to merge some of this into the SHIRE and RM
objects, but I'm not exactly sure if that's the right thing.  I
suppose the doCheckAuthN() and doHandlePOST() could be in the SHIRE
object and doCheckAuthZ() in the RM module.  Currently we're already
using them internally, and the new APIs would still continue to use
them, so I'd need to think a bit harder on where the lines are.

The doCheck...() functions are meant to be the common implementation
(note that they're static).  They uses the callback objects which are
server-specific implementations.

> Re: Logging, I think we can reuse the level enum from whatever logging
> library we're using (log4cpp for now) and avoid duplicating that. I also
> think with maybe a small bit of work, we could implement a log4cpp Appender
> that would write to the Apache log. Then more of the logging is consistent
> and adjustable via the same interface. The only question is whether it would
> work (not sure how it could get at the request object it needs, but there
> must be some interface for that). I'll take a quick look just to see if it's
> feasible.
>
> Note that IIS has no error log (I know, it's ridiculous), so I'm using
> log4cpp now anyway where applicable.

Sure it does: LogEvent().  I was modeling it after that.  The idea was
to offload more logging into the standard log4cpp shire log but use
this api for specific items to print into the webserver event log.  I
don't think we want to have log4cpp to print into the apache log.  Nor
do I want to print as many messages into this event log.

> Lessee...I think we probably want to widen the API around responses a bit,
> to allow for sending back responses that aren't errors, per se, so we want
> some ability to influence the status code. Particularly important in the
> future with SAMLv2 allowing authn requests to be form post and not redirect.

Hmm.  Ok, do you need anything other than the status code?  Do we need
to set the content-type, too, or is it always going to be text/html?

> Might be reasonable also to actually wrap a real "write data" callback so
> that the whole response need not be buffered ahead of time. May or may not
> be important.

I dont think it's all that important.  It's not like we're sending all
that much data.

> I need to think about the htaccess part a bit myself. I'd love to somehow
> link that back to the draft API I stuck in that I know needs some changes
> anyway, I'm just not sure how to bridge the two, but it ought to be
> possible.
>
> On the whole, I think this is reasonable.

Cool.  My hope is to get the API somewhat stabilized in the next week
so I can hunker down and work on it while I'm in FL.

> -- Scott

-derek

-- 
       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