Skip to Content.
Sympa Menu

shibboleth-dev - Re: Shibboleth OSID

Subject: Shibboleth Developers

List archive

Re: Shibboleth OSID


Chronological Thread 
  • From: Tom Scavo <>
  • To:
  • Subject: Re: Shibboleth OSID
  • Date: Wed, 16 Nov 2005 16:25:22 -0500
  • Domainkey-signature: a=rsa-sha1; q=dns; c=nofws; s=beta; d=gmail.com; h=received:message-id:date:from:to:subject:in-reply-to:mime-version:content-type:content-transfer-encoding:content-disposition:references; b=Ks3qfgBBPVpzDp67gWLxypGXw80SRN6PBv0mK5FEV0YuhnIOOLIXIchi/N7vg/kOXThAtLddKjqQpnruljuR0tBiP5dNoD/kJyr5V6YuP7TDtXw8aiCQuHS1ah491SxGqOnyt3ohGFpTlghAk64gBkyg1sXrijs/ld6ILcFGldI=

On 11/16/05,


<>
wrote:
>
> The primary difference between a
> "standard" Authn implementation using REMOTE_USER and a Shib
> implementation would be some thinking about how to handle REMOTE_USER
> values that looked like
> "user@domain".

Ouch. I just finished a name mapping plugin for emailAddress that
essentially concatenates REMOTE_USER with "@" plus a configured domain
string yielding precisely
"user@domain".
A fully qualified
REMOTE_USER value breaks this plugin. (Same would be true of a name
mapping plugin that naively implemented the SAML 2.0 kerberos name
identifier, btw.) I guess I could (and should) check REMOTE_USER to
see if it already satisfies the syntax requirements of emailAddress
before attempting to construct one. (Darn, I thought I was done with
that plugin. :)

More importantly, thinking out loud, we (GridShib) need to be careful
about hidden assumptions in certain profiles that separate the
production of the NameIdentifier from its consumption. The best
approach of course is to let Shib handle both ends of the name
mapping. (How does LionShare avoid this problem?)

Tom



Archive powered by MHonArc 2.6.16.

Top of Page