PingOne SSO cloud integrations

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

PingOne SSO cloud integrations

Schwendner, Joanne
I am wondering if anyone else on this list has done SAML integrations with users of  "PingOne SSO for SaaS Apps" -- PingFederate's cloud-based, multi-tenant product.

Recently we have had several different vendors present us with the same metadata that they generated from this product -- the VERY SAME for all vendors.  Apparently the SP metadata they get when they set up an integration uses the very same ACS endpoints and logout endpoints, and the very same signing/encryption cert.  A couple even had the same Entity ID.  (I turned those back.)

The most customization this product seems capable of is generating a unique Entity ID which is a long GUID-looking string.  I was told that the SP cert cannot be changed; that is what the product uses.  And the generic PingOne endpoints are also correct.  If I understand it correctly, we're expected to return our assertion to the same PingOne endpoint for all of these vendors, and PingOne sorts them out using that Entity ID, and directs them to the correct tenant.

I'd be interested in comments about this.

Joanne

---

Joanne Schwendner
Senior Developer - Web, Integration, & Identity Services
Brown University  



--
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: PingOne SSO cloud integrations

Nate Klingenstein-5
RE: PingOne SSO cloud integrations

Joanne,

 

It has been possible until now.  It's also possible that Ping has modified their product.

 

It seems very clear that the problem here is on the IdP side, as it should never use the same entityID(assuming it makes one for the SP or something -- it should consistently use just one for itself) or ACS points, to say nothing of the keypair.  This will all cause problems regardless of the SP.

 

I think their support would be a more appropriate place to pose this question than here.

 

Take care,

Nate.

 

--------

 

Signet ®

The Art of Access ®

 

Nate Klingenstein | Principal

https://www.signet.id/

 

-----Original message-----
From: Schwendner, Joanne
Sent: Tuesday, January 28 2020, 10:01 am
To: [hidden email]
Subject: PingOne SSO cloud integrations

I am wondering if anyone else on this list has done SAML integrations with users of  "PingOne SSO for SaaS Apps" -- PingFederate's cloud-based, multi-tenant product.
 
Recently we have had several different vendors present us with the same metadata that they generated from this product -- the VERY SAME for all vendors.  Apparently the SP metadata they get when they set up an integration uses the very same ACS endpoints and logout endpoints, and the very same signing/encryption cert.  A couple even had the same Entity ID.  (I turned those back.)
 
The most customization this product seems capable of is generating a unique Entity ID which is a long GUID-looking string.  I was told that the SP cert cannot be changed; that is what the product uses.  And the generic PingOne endpoints are also correct.  If I understand it correctly, we're expected to return our assertion to the same PingOne endpoint for all of these vendors, and PingOne sorts them out using that Entity ID, and directs them to the correct tenant.
 
I'd be interested in comments about this.
 
Joanne
 
---
 
Joanne Schwendner
Senior Developer - Web, Integration, & Identity Services
Brown University  
 
 
-- 

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: PingOne SSO cloud integrations

Cantor, Scott E.
In reply to this post by Schwendner, Joanne
On 1/28/20, 12:01 PM, "users on behalf of Schwendner, Joanne" <[hidden email] on behalf of [hidden email]> wrote:

> I am wondering if anyone else on this list has done SAML integrations with users of  "PingOne SSO for SaaS Apps" --
> PingFederate's cloud-based, multi-tenant product.

I have plenty of Ping SPs, I don't know how to distinguish which ones would be using this thing, unless they're recognizable. I have not noticed duplicate keys but probably would not notice that easily, though I would know if I'd been given a duplicate entityID.

> I'd be interested in comments about this.

Well, given the mass adoption of proxies across the research space, one might say what's good for the goose...

Proxies are proxies. They are what they are, and they'll be used to the limits of what people allow them to be used for.

I would probably raise a red flag about it if I caught a case like this with a duplicate key, but I can't say that I'm certain what the outcome would be. We regularly tolerate blatantly insecure practices by vendors, some mind-boggling. I can't imagine this being the straw that would break any camels for us, noting that we don't even require encryption to begin with.

-- 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: PingOne SSO cloud integrations

Peter Schober
In reply to this post by Schwendner, Joanne
* Schwendner, Joanne <[hidden email]> [2020-01-28 18:01]:
> Recently we have had several different vendors present us with the same
> metadata that they generated from this product -- the VERY SAME for all
> vendors.  Apparently the SP metadata they get when they set up an
> integration uses the very same ACS endpoints and logout endpoints, and the
> very same signing/encryption cert.  A couple even had the same Entity ID.
> (I turned those back.)

Well, with endpoints, keys and entityIDs being the same that just
tells me in no uncertain terms it's just a single SP.  Which would be
fine as long as the policy requirements (attribute release, strong
authentication, etc.) for everything behind that one SP were
sufficiently similar -- and of course the SP doesn't run into trouble
tracking just to what service I actually wanted to log in at any given
point.

I'm guessing the first condition may or may not be satisfied across
the products having chosen this SAML outsourcing service. The latter
condition -- the SP itself being fine with it -- already seems to have
failed since you wrote:

> PingOne sorts them out using that Entity ID, and directs them to the
> correct tenant.

So if they confuse themselfs by allowing duplicate entityIDs among
their tenants, well, nothing good can come from that.

-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: PingOne SSO cloud integrations

Schwendner, Joanne
I think the ones that sent metadata with the same EntityID didn't really know how to configure their service in this cloud product.
For the one that came with a unique Entity ID, at least we have something to go on to recognize the relying party.  But I still can't say I am comfortable with this.
Good idea to bring it up with PingOne support.

Joanne



On Tue, Jan 28, 2020 at 12:49 PM Peter Schober <[hidden email]> wrote:
* Schwendner, Joanne <[hidden email]> [2020-01-28 18:01]:
> Recently we have had several different vendors present us with the same
> metadata that they generated from this product -- the VERY SAME for all
> vendors.  Apparently the SP metadata they get when they set up an
> integration uses the very same ACS endpoints and logout endpoints, and the
> very same signing/encryption cert.  A couple even had the same Entity ID.
> (I turned those back.)

Well, with endpoints, keys and entityIDs being the same that just
tells me in no uncertain terms it's just a single SP.  Which would be
fine as long as the policy requirements (attribute release, strong
authentication, etc.) for everything behind that one SP were
sufficiently similar -- and of course the SP doesn't run into trouble
tracking just to what service I actually wanted to log in at any given
point.

I'm guessing the first condition may or may not be satisfied across
the products having chosen this SAML outsourcing service. The latter
condition -- the SP itself being fine with it -- already seems to have
failed since you wrote:

> PingOne sorts them out using that Entity ID, and directs them to the
> correct tenant.

So if they confuse themselfs by allowing duplicate entityIDs among
their tenants, well, nothing good can come from that.

-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]