[Shib-Users] is there a PHP service provider that will play nicely with the Shibboleth idp?

[Morgan Packard]

More generally,
Will Shibboleth work with any SAML-compliant service provider, or does a service provider need to be designed specifically to work with Shibboleth?
thanks,
-Morgan

[Chad La Joie]

Shib 2 should work, in most cases, with any SAML 2 product that
implements the SSO, artifact resolution, and attribute query profiles
(though obviously you need not use them all if your use case doesn't
require it). SAML 1 had a modest number of spaces where things where
left up to interpretations and so inter-vendor SAML 1 support tends to
be more brittle.

But in general, yeah, it should work with a SAML complaint service provider.

--
SWITCH
Serving Swiss Universities
--------------------------
Chad La Joie, Software Engineer, Net Services
Werdstrasse 2, P.O. Box, 8021 Zürich, Switzerland
phone +41 44 268 15 75, fax +41 44 268 15 68
chad....@switch.ch, http://www.switch.ch

[Nate Klingenstein]

Morgan,

And to tack on to Chad's answer with regards to your subject line,
you might consider looking at the simpleSAMLphp project, which is
probably right up your alley and does interoperate well with Shibboleth:

http://rnd.feide.no/simplesamlphp

Take care,
Nate.

[Morgan Packard]

Cool, thanks folks.
-Morgan

--
+++++++++++++++++++++++++++++++++++++++
morganpackard.com
myspace.com/morganpackard
finediving.org
anticipaterecordings.com
(646) 206-8337

[Peter Schober]

* Nate Klingenstein <n...@internet2.edu> [2008-12-30 16:04]:

> And to tack on to Chad's answer with regards to your subject line, you
> might consider looking at the simpleSAMLphp project, which is probably
> right up your alley and does interoperate well with Shibboleth:

Just a small note that simpleSAMLphp does not currently support
encrypted NameIDs (so you'd need to configure your Shib IdP to not
encrypt them for this relying party), also you will need PHP >= 5.2 on
the simpleSAMLphp SP.
Failing to have these both correct you won't get them to play, at
least with the SAML2 bindings and default settings on both sides.

cheers,
-peter

--
peter....@univie.ac.at - vienna university computer center
Universitaetsstrasse 7, A-1010 Wien, Austria/Europe
Tel. +43-1-4277-14155, Fax. +43-1-4277-9140

[Scott Cantor]

> Just a small note that simpleSAMLphp does not currently support
> encrypted NameIDs (so you'd need to configure your Shib IdP to not
> encrypt them for this relying party), also you will need PHP >= 5.2 on
> the simpleSAMLphp SP.
> Failing to have these both correct you won't get them to play, at
> least with the SAML2 bindings and default settings on both sides.

I thought the IdP default was encrypted assertions rather than NameID, is it
both that aren't supported?

-- Scott

[Peter Schober]

* Scott Cantor <cant...@osu.edu> [2008-12-30 20:03]:

> I thought the IdP default was encrypted assertions rather than
> NameID, is it both that aren't supported?

<ProfileConfiguration xsi:type="saml:SAML2SSOProfile"
encryptAssertions="conditional"
encryptNameIds="conditional" />

Turns out that the "conditions" are such that both are encrypted.

[Scott Cantor]

> Turns out that the "conditions" are such that both are encrypted.

Thanks. Probably makes sense to set the NameID option to false by default if
the other one is conditional.

-- Scott

[Nate Klingenstein]

I'm pretty sure that the default behavior is such that conditional for both means the NameID isn't encrypted if the assertion is encrypted.  It used to be true that both were encrypted.

[Chad La Joie]

It's still true that both are.

--

[Josh Howlett]

I'm confused - does the IdP now support encrypted NameID?

josh.

JANET(UK) is a trading name of The JNT Association, a company limited
by guarantee which is registered in England under No. 2881024
and whose Registered Office is at Lumen House, Library Avenue,
Harwell Science and Innovation Campus, Didcot, Oxfordshire. OX11 0SG

[chad....@switch.ch]

The 2.X IdP has always supported outbound encrypted NameIDs. It has never
supported inbound encrypted NameIDs. Not sure when we'll add that. At
least at the moment there isn't really a need for it.

[Peter Schober]

* Josh Howlett <Josh.H...@ja.net> [2009-01-05 11:20]:

> I'm confused - does the IdP now support encrypted NameID?

This was only meant as a heads-up for people running this combo, since
the Shib IdP by default produces encrypted NameIDs (inside encrypted
assertions) and simpleSAMLphp does not support those.
Sorry for adding confusion by posting about non-shibboleth software on
the shib list.

[Tom Scavo]

On Mon, Jan 5, 2009 at 4:10 PM, Peter Schober
<peter....@univie.ac.at> wrote:
>
> the Shib IdP by default produces encrypted NameIDs (inside encrypted
> assertions)

Really? That's odd. I thought the whole point of moving to attribute
push in Shib2 was to make it easier for the deployer. Of course
encryption requires the SP to (have|configure|protect) a private key.
Has anything been gained in terms of ease of deployment?

A by-product of (or perhaps the point of) using SAML metadata is that
the SP need not sign requests and therefore need not
(have|configure|protect) a signing key. Removing attribute query (in
favor of attribute push) means the SP need not issue SOAP-based
requests and therefore need not (have|configure|protect) a
back-channel TLS key. Encryption seems to contradict the trend
towards a more lightweight SP deployment.

Of course someone will say we simply can't send identity attributes
through the browser. Well then don't (by default). Pre-configure the
IdP to send only benign attributes (like eduPersonAffiliation) by
default. Let the deployer make a conscious decision about sending
anything more.

Tom

[Chad La Joie]

The problem is not, and has never been, whether the SP has a key or
not. The problem is that people can't read and type an openssl
command. Now that the installers generate the keypairs and plug them
in to the correct spots in the config files, there isn't an issue.
People run the installers, assume Scott and I have done the propers
incantations on their behalf, and go on with their life.

SWITCH
Service Swiss Universities
------------------------------------

Chad La Joie, Software Engineer, Net Services

Werdstrasse 2, P.O. Box, 8021, Zürich, Switzerland

[Scott Cantor]

> Really? That's odd. I thought the whole point of moving to attribute
> push in Shib2 was to make it easier for the deployer.

Actually, the point was to make it easier for us to support. So far at least
encryption hasn't been particularly troublesome (which surprises me a
little). Configuring SSL is the biggest problem. Not for me, and not for
most of the developers, but for people in general apparently.

> Of course
> encryption requires the SP to (have|configure|protect) a private key.
> Has anything been gained in terms of ease of deployment?

There's an argument to make about whether SPs should have keys or not, but
which is really more about whether SPs should all be known to IdPs or not.
If you assume registration of SPs (via federations or otherwise), then
whether you have a key or not doesn't make a great deal of difference,
especially when its just generated.

And of course I don't see why the defaults should dictate anything. If the
community of interest decides that SPs shouldn't get keys, then you turn it
off.

> Of course someone will say we simply can't send identity attributes
> through the browser. Well then don't (by default). Pre-configure the
> IdP to send only benign attributes (like eduPersonAffiliation) by
> default. Let the deployer make a conscious decision about sending
> anything more.

That would be a problem today since it won't query for anything if it gets
something to begin with.

-- Scott