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: Thu, 17 Nov 2005 11:53:54 -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=psobLUpMKt4Q2YWOrsHS/5F+3auWI4A5xd6ZnUH6/ZRUPms6BaWj4Rvah8of30qcN/J87rDiR3LvASRkKOtuZJct7sWmX5qKEfZr7jbCfUim6dn1036zX+yCzvjJiqYrB2+GSB+CErPL5fLvGv4IkimEXoca+0++tsQFjINCFfc=

On 11/17/05,


<>
wrote:
>
> I think the shib distribution defaults to mapping EPPN to
> REMOTE_USER. For instance, that's how the Shib Wiki works....

I'd be surprised if this were in fact true (it would blow my
understanding of name mappings out of the water :). As I understand
it, on the SSO end, REMOTE_USER is typically set to "user" (no
domain), which becomes the local principal name. This is mapped to a
NameIdentifier and then on the back end, the name mapper reverses the
process, recovering "user". Finally, the resolver qualifies this
local principal name with a scope value to obtain
"user@domain".

If REMOTE_USER is of the form
"user@domain"
initially (and I can see
why you might want this), a bunch of stuff on the back end has to
change. Additionally, if you're using emailAddress or kerberos name
identifiers (not common today, I know), the name mapping process
itself becomes somewhat complicated. This probably argues for opaque
identifiers more than anything else.

Here's a related diagram:

https://authdev.it.ohio-state.edu/twiki/bin/view/GridShib/MyProxyOrIdPFirst

If I'm wrong about any of this, someone please correct me since much
of what we're doing right now depends on this stuff.

Thanks,
Tom



Archive powered by MHonArc 2.6.16.

Top of Page