Ping Federate(SP) with Shib 1.x (IdP)

classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Ping Federate(SP) with Shib 1.x (IdP)

Kevin Hue

Hi Everyone,

I have a client who is using Shibboleth 1.x, IdP Role whom I am trying establish SSO with. My knowledge of Shibboleth is limited and so I've come to this group for advice. The problem I am facing is the SAML assertion coming to my SSO service (Ping Federate) does not have the Attribute I am expecting (EmployeeNumber). The SSO does get authenticated and is allowed into  my application, however, without the unique identifier for the individual, I am unable to assign the correct role. Here are the details:

General Flow

Individual navigates to SP website, containing a link (Session Initiator URL)  --> Individual is navigated to IdP site and logs in --> Individual is forwarded to SP site  --> SSO authentication occurs. Individual is allowed into SP website


  • Ping Federate(SP) with Shib 1.x (IdP)
  • EmployeeNumber attribute not sent in SAML assertion to SP (SP does not support Attribute Querying with SAML 1.1)
  • IdP is unable to place the EmployeeNumber attribute within the SAML Subject
  • IdP logs show Attribute Exchange not happening, but do not know the reason
  • resolver.xml and relyingparty.xml not matching. I'm told IdP has all they need in the metadata SP has defined on the Incommon site
  • No IdP logs on unsuccessful SSO attempts

Leads and Questions I am working on
  • Review meta data on the Incommon site to make sure it is correct.
  • Is it possible that I can format the Session Initiator URL in such a way to resolvet his issue?
  • Due to my lack of knowledge in Shibboleth, it's very possible that I am not asking the correct questions. What pertinent details do you feel I should get from the client?

I really appreciate any suggestions and please let me know if I need to clarify on anything stated. Thank you all.

-Kevin

Confidentiality Note: This message and any accompanying attachments contain information from the law firm Fragomen, Del Rey, Bernsen & Loewy, LLP, its subsidiaries or affiliates and may contain information which is confidential or privileged. The information is intended for the individual(s) or organization(s) named above. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution or use of the contents of this message is prohibited. If you have received this message in error, please notify the sender by e-mail or contact our offices at "[hidden email]" and delete this message. Thank you.
Reply | Threaded
Open this post in threaded view
|

Re: Ping Federate(SP) with Shib 1.x (IdP)

Tom Scavo
On Fri, Oct 1, 2010 at 2:37 PM, Kevin Hue <[hidden email]> wrote:
>
> Ping Federate(SP) with Shib 1.x (IdP)
> EmployeeNumber attribute not sent in SAML assertion to SP (SP does not
> support Attribute Querying with SAML 1.1)

That's a problem since Shib 1.x IdP prefers attribute query.

> IdP is unable to place the EmployeeNumber attribute within the SAML Subject

Not surprising since Shib 1.x IdP prefers transient name identifier.
Unlikely they'll be able to shoehorn EmployeeNumber into SAML Subject.
A custom attribute may be required.

> IdP logs show Attribute Exchange not happening, but do not know the reason

Either the SP supports attribute query or it does not. If not, that
could be the problem right there. Don't recall if Shib 1.x supports
attribute push. Have you checked the wiki?

https://spaces.internet2.edu/display/SHIB/

> resolver.xml and relyingparty.xml not matching. I'm told IdP has all they
> need in the metadata SP has defined on the Incommon site

Yes, *your* metadata is just fine.

Tom
Reply | Threaded
Open this post in threaded view
|

RE: Ping Federate(SP) with Shib 1.x (IdP)

Cantor, Scott E.
In reply to this post by Kevin Hue
> * Due to my lack of knowledge in Shibboleth, it's very possible that I
> am not asking the correct questions. What pertinent details do you feel I
> should get from the client?

Mainly whether or not they're specifically telling the IdP to push the
attributes with SSO.

https://spaces.internet2.edu/display/SHIB/Interoperate+with+a+commerical+SAM
L+Service+Provider

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Ping Federate(SP) with Shib 1.x (IdP)

Kevin Hue

Scott & Tom,

Thank you both for your inputs. The SP does not support attribute query and it sounds like I may be able to request a change on the IdP side (Shibboleth 1.x) to add/update the RelyingParty node with parameter "forceAttributePush" with a value of "true".  This parameter is off by default and as long as the entityID matches up, this should get the IdP to push EmployeeNumber in the inital POST transaction.

Thanks again,
-Kevin


Confidentiality Note: This message and any accompanying attachments contain information from the law firm Fragomen, Del Rey, Bernsen & Loewy, LLP, its subsidiaries or affiliates and may contain information which is confidential or privileged.  The information is intended for the individual(s) or organization(s) named above. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution or use of the contents of this message is prohibited. If you have received this message in error, please notify the sender by e-mail or contact our offices at '[hidden email]' and delete this message. Thank you.



Scott Cantor <[hidden email]>
Sent by: <[hidden email]>

10/01/2010 01:00 PM

Please respond to
[hidden email]

To
<[hidden email]>
cc
"'ALICE KISLING'" <[hidden email]>
Subject
RE: [Shib-Users] Ping Federate(SP) with Shib 1.x (IdP)





> *                 Due to my lack of knowledge in Shibboleth, it's very possible that I
> am not asking the correct questions. What pertinent details do you feel I
> should get from the client?

Mainly whether or not they're specifically telling the IdP to push the
attributes with SSO.

https://spaces.internet2.edu/display/SHIB/Interoperate+with+a+commerical+SAM
L+Service+Provider

-- Scott





Confidentiality Note: This message and any accompanying attachments contain information from the law firm Fragomen, Del Rey, Bernsen & Loewy, LLP, its subsidiaries or affiliates and may contain information which is confidential or privileged. The information is intended for the individual(s) or organization(s) named above. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution or use of the contents of this message is prohibited. If you have received this message in error, please notify the sender by e-mail or contact our offices at "[hidden email]" and delete this message. Thank you.
Reply | Threaded
Open this post in threaded view
|

RE: Ping Federate(SP) with Shib 1.x (IdP)

Cantor, Scott E.
> Thank you both for your inputs. The SP does not support attribute query
and
> it sounds like I may be able to request a change on the IdP side
(Shibboleth
> 1.x) to add/update the RelyingParty node with parameter
"forceAttributePush"
> with a value of "true".  This parameter is off by default and as long as
the
> entityID matches up, this should get the IdP to push EmployeeNumber in the
> inital POST transaction.

In an attribute, yes. Getting it into the Subject would be a different set
of changes (and they're much more complex).

-- Scott


Reply | Threaded
Open this post in threaded view
|

RE: Ping Federate(SP) with Shib 1.x (IdP)

Kevin Hue

Thanks for pointing that out. The EmployeeNumber doesn't need to be in the SAML Subject. I suggested that as an alternative. If EmployeeNumber can be sent as an attribute, the SP can work with it.

Will keep this group posted
-Kevin


Confidentiality Note: This message and any accompanying attachments contain information from the law firm Fragomen, Del Rey, Bernsen & Loewy, LLP, its subsidiaries or affiliates and may contain information which is confidential or privileged.  The information is intended for the individual(s) or organization(s) named above. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution or use of the contents of this message is prohibited. If you have received this message in error, please notify the sender by e-mail or contact our offices at '[hidden email]' and delete this message. Thank you.



Scott Cantor <[hidden email]>
Sent by: <[hidden email]>

10/01/2010 02:36 PM

Please respond to
[hidden email]

To
<[hidden email]>
cc
"'ALICE KISLING'" <[hidden email]>, <[hidden email]>
Subject
RE: [Shib-Users] Ping Federate(SP) with Shib 1.x (IdP)





> Thank you both for your inputs. The SP does not support attribute query
and
> it sounds like I may be able to request a change on the IdP side
(Shibboleth
> 1.x) to add/update the RelyingParty node with parameter
"forceAttributePush"
> with a value of "true".  This parameter is off by default and as long as
the
> entityID matches up, this should get the IdP to push EmployeeNumber in the
> inital POST transaction.

In an attribute, yes. Getting it into the Subject would be a different set
of changes (and they're much more complex).

-- Scott





Confidentiality Note: This message and any accompanying attachments contain information from the law firm Fragomen, Del Rey, Bernsen & Loewy, LLP, its subsidiaries or affiliates and may contain information which is confidential or privileged. The information is intended for the individual(s) or organization(s) named above. If you are not the intended recipient, be aware that any review, disclosure, copying, distribution or use of the contents of this message is prohibited. If you have received this message in error, please notify the sender by e-mail or contact our offices at "[hidden email]" and delete this message. Thank you.