Using scoped attributes as the C14N subject

[Wessel, Keith]

In that case, is there any way I can validate and strip off a domain before sending to Kerberos but still have it afterwards? Wow, after typing that, it sounds like a lot more work than it's worth.

If I pass netid at campus.edu to Shibboleth or netid at my.kerberos.realm, authentication fails. It only succeeds if I just pass in a NetID which, as you explained, is why I'm just getting back the username.

Sounds like there's no easy way around that. True?

Keith


-----Original Message-----
From: Cantor, Scott <cantor.2 at osu.edu> 
Sent: Tuesday, August 16, 2022 2:11 PM
To: Shib Users <users at shibboleth.net>
Cc: Wessel, Keith <kwessel at illinois.edu>
Subject: Re: Using scoped attributes as the C14N subject

On 8/16/22, 3:00 PM, "users on behalf of Wessel, Keith via users" <users-bounces at shibboleth.net on behalf of users at shibboleth.net> wrote:

>    One somewhat related follow-up to this. I _thought_ that Microsoft 
> AD Kerberos returned a scoped value as the principal and that, after 
> all this time, my regex transform was parsing off the domain. But it 
> appears that my regex transform was doing nothing as the log suggests:

The username there is simply what the user enters, along with any  transforms you apply to that step. It's not what Kerberos puts in a ticket or something like that.

>    This may be out of scope for this list, but can anyone shed any 
> light on if there's a Kerberos or Shib setting to get a fully "scoped" 
> value back from AD Kerberos? Or is this all on Microsoft's side?

Just how the IdP works, the c14n step is the process that lets you turn something from the user's data entry into a normalized value, which is in part there to make resolver config cleaner by ensuring it's done outside of that layer.

Other login methods have different sorts of behavior but that's how Password works.

-- Scott