ADFS to Shibboleth

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

ADFS to Shibboleth

Nancy Kerr

We are trying to transfer the info that is in the EmployeeID attribute in AD to a Shibboleth.  We have the following claim rules set-up.

 

 

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

=> issue(store = "Active Directory", types = ("EmployeeID"), query = ";employeeID;{0}", param = c.Value);

 

 

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]

=> issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.6", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimpropert ies/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrnameformat:uri");

 

The only info that that is being sent is the e-mail address.

 

Nancy

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ADFS to Shibboleth

Nate Klingenstein-2
Nancy,

It might be a copy/paste issue, but you have a space in the property you defined for UPN:


I don't know enough about claim configuration to be much more useful than that, but it seems like a good thing to check.

Thanks,
Nate.


On Wed, Jun 27, 2018 at 11:23 AM, Nancy Kerr <[hidden email]> wrote:

We are trying to transfer the info that is in the EmployeeID attribute in AD to a Shibboleth.  We have the following claim rules set-up.

 

 

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

=> issue(store = "Active Directory", types = ("EmployeeID"), query = ";employeeID;{0}", param = c.Value);

 

 

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]

=> issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.6", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimpropert ies/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrnameformat:uri");

 

The only info that that is being sent is the e-mail address.

 

Nancy

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ADFS to Shibboleth

Nancy Kerr

I removed the space. Now nothing is being sent.

 

 

Nancy A. Kerr

LAN Administrator

Mount Saint Vincent University

166 Bedford Highway

Halifax, NS  B3M 2J6

 

Tel: (902) 457-6685

Fax: (902) 445-4121

www.msvu.ca

 

From: users <[hidden email]> On Behalf Of Nate Klingenstein
Sent: Wednesday, June 27, 2018 3:30 PM
To: Shib Users <[hidden email]>
Subject: Re: ADFS to Shibboleth

 

Nancy,

 

It might be a copy/paste issue, but you have a space in the property you defined for UPN:

 

 

I don't know enough about claim configuration to be much more useful than that, but it seems like a good thing to check.

 

Thanks,

Nate.

 

 

On Wed, Jun 27, 2018 at 11:23 AM, Nancy Kerr <[hidden email]> wrote:

We are trying to transfer the info that is in the EmployeeID attribute in AD to a Shibboleth.  We have the following claim rules set-up.

 

 

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]

=> issue(store = "Active Directory", types = ("EmployeeID"), query = ";employeeID;{0}", param = c.Value);

 

 

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]

=> issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.6", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimpropert ies/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrnameformat:uri");

 

The only info that that is being sent is the e-mail address.

 

Nancy

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]

 


--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ADFS to Shibboleth

Peter Schober
In reply to this post by Nancy Kerr
* Nancy Kerr <[hidden email]> [2018-06-27 20:24]:

> We are trying to transfer the info that is in the EmployeeID
> attribute in AD to a Shibboleth.  We have the following claim rules
> set-up.
>
> c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
> => issue(store = "Active Directory", types = ("EmployeeID"), query = ";employeeID;{0}", param = c.Value);
>
>
> c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
> => issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.6", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimpropert ies/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrnameformat:uri");

Your SP log files will tell you that the SP is recieving the attribute
but that it is throwing away the value:

You're encoding that attribute to the formal name of the
eduPersonPrincipalName attribute. That attribute has built-in policy
rules in the Shibboleth SP software in order to prevent one IDP
asserting values in the domain ("scopes", specifically) of another
IDP.

The proper way to fix that (and keep that protection the software is
providing) is by extending the asserting IDP's SAML Metadata with a
shibmd:Scope attribute, see for example an IDP that asserts
eduPersonPrincipalName values that look like "[hidden email]":

https://met.refeds.org/met/entity/https%3A//idp.aco.net/idp/shibboleth/?viewxml=true&federation=aconet-identity-federation-eduidat
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <md:Extensions>
    <shibmd:Scope regexp="false">aco.net</shibmd:Scope>
  etc.

If that's already in place with a proper scope/domain then the
asserting IDP is asserting the wrong scope.

You could also work around that brokenness by turning off the
SP's protection for scoped attributes, but that's a bad idea.

If you did not intend for the attribute
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" to end up
as eduPersonPrincipalName specifically you can map it to a different
attribute on-the-wire, of course, in which case the SP also cannot
offer the same protection, as that's specific to a few attributes.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ADFS to Shibboleth

Nancy Kerr
We are looking to sync\transfer EmployeeID from ADFS (on prem) to an external Shibboleth system.

Nancy


Nancy A. Kerr
LAN Administrator
Mount Saint Vincent University
166 Bedford Highway
Halifax, NS  B3M 2J6

Tel: (902) 457-6685
Fax: (902) 445-4121
www.msvu.ca

-----Original Message-----
From: users <[hidden email]> On Behalf Of Peter Schober
Sent: Thursday, June 28, 2018 7:33 AM
To: [hidden email]
Subject: Re: ADFS to Shibboleth

* Nancy Kerr <[hidden email]> [2018-06-27 20:24]:

> We are trying to transfer the info that is in the EmployeeID attribute
> in AD to a Shibboleth.  We have the following claim rules set-up.
>
> c:[Type ==
> "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccoun
> tname", Issuer == "AD AUTHORITY"] => issue(store = "Active Directory",
> types = ("EmployeeID"), query = ";employeeID;{0}", param = c.Value);
>
>
> c:[Type ==
> "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn"]
> => issue(Type = "urn:oid:1.3.6.1.4.1.5923.1.1.1.6", Value = c.Value,
> Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproper
> t ies/attributename"] =
> "urn:oasis:names:tc:SAML:2.0:attrnameformat:uri");

Your SP log files will tell you that the SP is recieving the attribute but that it is throwing away the value:

You're encoding that attribute to the formal name of the eduPersonPrincipalName attribute. That attribute has built-in policy rules in the Shibboleth SP software in order to prevent one IDP asserting values in the domain ("scopes", specifically) of another IDP.

The proper way to fix that (and keep that protection the software is
providing) is by extending the asserting IDP's SAML Metadata with a shibmd:Scope attribute, see for example an IDP that asserts eduPersonPrincipalName values that look like "[hidden email]":

https://met.refeds.org/met/entity/https%3A//idp.aco.net/idp/shibboleth/?viewxml=true&federation=aconet-identity-federation-eduidat
<md:IDPSSODescriptor protocolSupportEnumeration="urn:oasis:names:tc:SAML:2.0:protocol">
  <md:Extensions>
    <shibmd:Scope regexp="false">aco.net</shibmd:Scope>
  etc.

If that's already in place with a proper scope/domain then the asserting IDP is asserting the wrong scope.

You could also work around that brokenness by turning off the SP's protection for scoped attributes, but that's a bad idea.

If you did not intend for the attribute
"http://schemas.xmlsoap.org/ws/2005/05/identity/claims/upn" to end up as eduPersonPrincipalName specifically you can map it to a different attribute on-the-wire, of course, in which case the SP also cannot offer the same protection, as that's specific to a few attributes.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ADFS to Shibboleth

Cantor, Scott E.
> We are looking to sync\transfer EmployeeID from ADFS (on prem) to an
> external Shibboleth system.

Then why are you attempting to encode it under the standard name for eduPersonPrincipalName? That's not a correct thing to do.

Were I to do this, I would use the name for employeeNumber, which happens to be urn:oid:2.16.840.1.113730.3.1.3

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ADFS to Shibboleth

Nancy Kerr
That was the info were originally give.  The following is what I have for the claims rules.  The EmployeeID is not being passed to the Shibboleth system.

Nancy

Claim Rule #1

c:[Type == "http://schemas.microsoft.com/ws/2008/06/identity/claims/windowsaccountname", Issuer == "AD AUTHORITY"]
 => issue(store = "Active Directory", types = ("EmployeeNumber"), query = ";employeeID;{0}", param = c.Value);

Claim Rule #2

c:[Type == "http://schemas.xmlsoap.org/ws/2005/05/identity/claims/employeeNumber"]
 => issue(Type = "urn:oid:2.16.840.1.113730.3.1.3", Value = c.Value, Properties["http://schemas.xmlsoap.org/ws/2005/05/identity/claimproperties/attributename"] = "urn:oasis:names:tc:SAML:2.0:attrnameformat:uri");




-----Original Message-----
From: users <[hidden email]> On Behalf Of Cantor, Scott
Sent: Thursday, June 28, 2018 3:23 PM
To: Shib Users <[hidden email]>
Subject: RE: ADFS to Shibboleth

> We are looking to sync\transfer EmployeeID from ADFS (on prem) to an
> external Shibboleth system.

Then why are you attempting to encode it under the standard name for eduPersonPrincipalName? That's not a correct thing to do.

Were I to do this, I would use the name for employeeNumber, which happens to be urn:oid:2.16.840.1.113730.3.1.3

-- Scott

--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ADFS to Shibboleth

Peter Schober
* Nancy Kerr <[hidden email]> [2018-06-29 14:08]:
> The EmployeeID is not being passed to  the Shibboleth system.

1. How exactly do you determine that?

2. If it's not being passed to the SP, what should the SP do about it?

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

RE: ADFS to Shibboleth

Nancy Kerr
When I view the log file I see that "REMOTE_USER ="


Nancy A. Kerr
LAN Administrator
Mount Saint Vincent University
166 Bedford Highway
Halifax, NS  B3M 2J6

Tel: (902) 457-6685
Fax: (902) 445-4121
www.msvu.ca


-----Original Message-----
From: users <[hidden email]> On Behalf Of Peter Schober
Sent: Friday, June 29, 2018 9:36 AM
To: [hidden email]
Subject: Re: ADFS to Shibboleth

* Nancy Kerr <[hidden email]> [2018-06-29 14:08]:
> The EmployeeID is not being passed to  the Shibboleth system.

1. How exactly do you determine that?

2. If it's not being passed to the SP, what should the SP do about it?

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]
Reply | Threaded
Open this post in threaded view
|

Re: ADFS to Shibboleth

Peter Schober
* Nancy Kerr <[hidden email]> [2018-06-29 14:41]:
> When I view the log file I see that "REMOTE_USER ="

That just means that no attribute which is being mapped to REMOTE_USER
in your shibboleth2.xml was available after filtering.

So have you looked at the Shibboleth SP's log files (as said earlier)?
https://wiki.shibboleth.net/confluence/display/SHIB2/NativeSPTroubleshootingTactics

shibd.log will tell you what it received and skipped or filtered out.
transaction.log will tell you what it successfully mapped.

If the SAML is *not* encrypted you can see everything in the browser,
e.g. easiest with Mozilla Firefox using the SAMLtracer extension.

If the SAML is encrypted you can raise the log level at the SP to see
all the decrypted data, e.g. by adding the line
  log4j.category.Shibboleth.SSO=DEBUG
to your shibd.logger and restaring the SP.

-peter
--
For Consortium Member technical support, see https://wiki.shibboleth.net/confluence/x/coFAAg
To unsubscribe from this list send an email to [hidden email]