Skip to Content.
Sympa Menu

shibboleth-dev - Re: Exporting attributes -> headers

Subject: Shibboleth Developers

List archive

Re: Exporting attributes -> headers


Chronological Thread 
  • From: "Sridhar Muppidi" <>
  • To: Scott Cantor <>
  • Cc: ,
  • Subject: Re: Exporting attributes -> headers
  • Date: Mon, 22 Apr 2002 19:29:56 -0500

I made changes to the module to export the Affiliation as
HTTP_SHIB_EP_AFFILIATION environment variable. You can test it out at
http://shib1.internet2.edu/cgi-bin/env.pl

Let me know if there are any problems.

Regards,
-Sridhar




|---------+------------------------------------>
| | Scott Cantor |
| |
<>
|
| | Sent by: |
| |
owner-mace-shib-design@in|
| | ternet2.edu |
| | |
| | |
| | 04/17/2002 10:25 PM |
| | |
|---------+------------------------------------>

>-------------------------------------------------------------------------------------------------------------------|
|
|
| To:

|
| cc:
|
| Subject: Exporting attributes -> headers
|
|
|
|
|

>-------------------------------------------------------------------------------------------------------------------|



So I've given this a little bit of thought, plus I've looked into what I
think needs to be specified by the architecture itself. I've gone back
and forth on that, but I think I'd like to propose three immediate
steps:

1) Insert into the architecture spec a well-defined way of exporting all
known attributes for the user into a single HTTP header. This could be
done by exporting the whole assertion, or just the attribute statement,
or the attributes themselves, in XML. Or we could serialize the
attributes some other way. I suggest we begin to decide on this, but
that we leave it out of the alpha.

2) Design the target module to use a configurable mapping of attribute
names to HTTP header names. These would be based on the needs of the
target site, though we can suggest something logical to encourage
consistency. This isn't too hard to build, but we could leave it out of
the alpha as well. Note that even EPPN will be handled this way, by
specifying EPPN->REMOTE_USER, and letting the module special-case that
header.

3) Finally, we handle affiliation for now by choosing a header name that
would be consistent with our expected suggestions in (2) and just stick
it there for the alpha.

My justification for (1) is that since the attributes aren't specified
anywhere in the arch doc, it would be a mistake to work at the
per-attribute level in specifying header names.

My justification for (2) is simply pragmatic; apps are all over the map
in what they need, and this is the most friendly to legacy integration.
It's not hard, and about the only thing we need to work through is
multiple values. I prefer combining them in one header with a separator
of some sort. Maybe I'm biased because my primary web tool handles lists
really cleanly...

My justification for (3) is time. Let's get the alpha done already and
move on. I suggest we use HTTP_SHIB_EP_AFFILIATION.

Thoughts?

-- Scott





------------------------------------------------------mace-shib-design-+
For list utilities, archives, subscribe, unsubscribe, etc. please visit the
ListProc web interface at

http://archives.internet2.edu/

------------------------------------------------------mace-shib-design--




Archive powered by MHonArc 2.6.16.

Top of Page