inCommon and Attribute Service
40 views
Skip to first unread message
Josef Fortier
Jan 30, 2014, 2:30:35 PM1/30/14
to simple...@googlegroups.com
We've had a SimpleSAMLphp IDP working with a few vendors for a half year or so. I'd like to add inCommon federation.
The inCommon federation IDP setup wizard has a field labled "AttributeAuthorityDescriptor:(optional)" which, despite being labeled "optional" appears to actually be "required" (at least I've found no way of avoiding a roadblock there).
As near as I can tell from browsing the list archives, it like simpleSAMLphp doesn't easily support this. If I'm reading things correctly, it looks like it's possible to build an external service to support this, although I didn't find a lot of info there.
In some questions on the Shibboleth list, I received some assurance that there were indeed SSP IDPs federated in inCommon.
I'd love it if anyone had any guidance here.
* Is anyone using an SSP IDP to federate with inCommon?
* Has anyone built an Attribute Service Wrapper?
* Is there a way to cooerce SSP to give the right info?
Thanks in advance for any help!
Peter Schober
Jan 31, 2014, 10:09:31 AM1/31/14
to simple...@googlegroups.com
* Josef Fortier <josef....@gmail.com> [2014-01-30 21:34]:
personally consider that broken, but either way that's not an issue
for this list but for InCommon operations.
(Fyi, not all IDPs have AAs, that's a simple fact. Hence requiring the
entry of data for one would only lead to either no IDP registration or
bogus data for the AA, doing everyone a disservice.)
> As near as I can tell from browsing the list archives, it like
> simpleSAMLphp doesn't easily support this. If I'm reading things
> correctly, it looks like it's possible to build an external service
> to support this, although I didn't find a lot of info there.
The short answer is to talk to InCommon and let them register your IDP
without an AA. You don't strictly need one for most or all the SAML
SPs I know and not all registered AAs seem to be working, across
Identity Federations.
To answer the question more relevant to this list: Yaco has
contributed code that allows to add an AA to SSP,
cf. "attributequeryserver"
https://github.com/Yaco-Sistemas/asynchronous-provisioning
I'd be interested in feedback about this (from outside of Yaco, if
possible :)) and possible inclusion with SSP's distributed list of
modules.
-peter
> The inCommon federation IDP setup wizard has a field labled
> "AttributeAuthorityDescriptor:(optional)" which, despite being
> labeled "optional" appears to actually be "required" (at least I've
> found no way of avoiding a roadblock there).
If InCommon in fact required an AA for registration of an IDP I'd
> "AttributeAuthorityDescriptor:(optional)" which, despite being
> labeled "optional" appears to actually be "required" (at least I've
> found no way of avoiding a roadblock there).
personally consider that broken, but either way that's not an issue
for this list but for InCommon operations.
(Fyi, not all IDPs have AAs, that's a simple fact. Hence requiring the
entry of data for one would only lead to either no IDP registration or
bogus data for the AA, doing everyone a disservice.)
> As near as I can tell from browsing the list archives, it like
> simpleSAMLphp doesn't easily support this. If I'm reading things
> correctly, it looks like it's possible to build an external service
> to support this, although I didn't find a lot of info there.
without an AA. You don't strictly need one for most or all the SAML
SPs I know and not all registered AAs seem to be working, across
Identity Federations.
To answer the question more relevant to this list: Yaco has
contributed code that allows to add an AA to SSP,
cf. "attributequeryserver"
https://github.com/Yaco-Sistemas/asynchronous-provisioning
I'd be interested in feedback about this (from outside of Yaco, if
possible :)) and possible inclusion with SSP's distributed list of
modules.
-peter
Tom Scavo
Jan 31, 2014, 10:46:37 AM1/31/14
to simpleSAMLphp, Tom Scavo
Hi Josef,
On Thu, Jan 30, 2014 at 2:30 PM, Josef Fortier <josef....@gmail.com> wrote:
> We've had a SimpleSAMLphp IDP working with a few vendors for a half year or
> so. I'd like to add inCommon federation.
>
> The inCommon federation IDP setup wizard has a field labled
> "AttributeAuthorityDescriptor:(optional)" which, despite being labeled
> "optional" appears to actually be "required" (at least I've found no way of
> avoiding a roadblock there).
I don't think that's true, but if you're having trouble creating IdP
metadata without an AttributeAuthorityDescriptor, please email
ad...@incommon.org so we can get to the bottom of it.
> As near as I can tell from browsing the list archives, it like simpleSAMLphp
> doesn't easily support this.
AFAIK, SSP doesn't support attribute query out of the box, and so SSP
doesn't support SAML1 very well. OTOH, attribute query is not needed
for SAML2, and in fact is NOT RECOMMENDED for SAML2, so SSP should be
fine for an IdP that supports SAML2 only.
Tom
On Thu, Jan 30, 2014 at 2:30 PM, Josef Fortier <josef....@gmail.com> wrote:
> We've had a SimpleSAMLphp IDP working with a few vendors for a half year or
> so. I'd like to add inCommon federation.
>
> The inCommon federation IDP setup wizard has a field labled
> "AttributeAuthorityDescriptor:(optional)" which, despite being labeled
> "optional" appears to actually be "required" (at least I've found no way of
> avoiding a roadblock there).
metadata without an AttributeAuthorityDescriptor, please email
ad...@incommon.org so we can get to the bottom of it.
> As near as I can tell from browsing the list archives, it like simpleSAMLphp
> doesn't easily support this.
doesn't support SAML1 very well. OTOH, attribute query is not needed
for SAML2, and in fact is NOT RECOMMENDED for SAML2, so SSP should be
fine for an IdP that supports SAML2 only.
Tom
Peter Schober
Jan 31, 2014, 10:58:55 AM1/31/14
to simpleSAMLphp
* Tom Scavo <trs...@gmail.com> [2014-01-31 16:46]:
include the (unencrypted) attribute assertion in the first place.
Or if the SP could not process the attribute assertion presented that
way, insisting on fetching it afterwards via SOAP.
I would hope that the latter is sufficiently rare (ideally
non-existent) and the former is a decision for the IdP organistion to
make. For the attributes we send to SAML1-only SPs we don't care about
potential exposure to the browser during transit (non-PII).
> OTOH, attribute query is not needed for SAML2, and in fact is NOT
> RECOMMENDED for SAML2, so SSP should be fine for an IdP that
> supports SAML2 only.
I just had a /very/ brief look at the attributequeryserver from Yaco
and I think it's not usable as is, at least due to
https://github.com/Yaco-Sistemas/asynchronous-provisioning/issues/1
(unless I'm mistaken and things are not as I assumed, of course).
Given that that code hasn't seen any changes for 2 years (and consists
of a single commit) and that the author of that code also isn't with
Yaco anymore, one could get the impression of that code being
unmaintained and abandoned.
-peter
> AFAIK, SSP doesn't support attribute query out of the box, and so SSP
> doesn't support SAML1 very well.
That would only be an issue if one would under no circumstances just
> doesn't support SAML1 very well.
include the (unencrypted) attribute assertion in the first place.
Or if the SP could not process the attribute assertion presented that
way, insisting on fetching it afterwards via SOAP.
I would hope that the latter is sufficiently rare (ideally
non-existent) and the former is a decision for the IdP organistion to
make. For the attributes we send to SAML1-only SPs we don't care about
potential exposure to the browser during transit (non-PII).
> OTOH, attribute query is not needed for SAML2, and in fact is NOT
> RECOMMENDED for SAML2, so SSP should be fine for an IdP that
> supports SAML2 only.
and I think it's not usable as is, at least due to
https://github.com/Yaco-Sistemas/asynchronous-provisioning/issues/1
(unless I'm mistaken and things are not as I assumed, of course).
Given that that code hasn't seen any changes for 2 years (and consists
of a single commit) and that the author of that code also isn't with
Yaco anymore, one could get the impression of that code being
unmaintained and abandoned.
-peter
Tom Scavo
Jan 31, 2014, 11:16:33 AM1/31/14
to simpleSAMLphp
On Fri, Jan 31, 2014 at 10:58 AM, Peter Schober
<peter....@univie.ac.at> wrote:
> * Tom Scavo <trs...@gmail.com> [2014-01-31 16:46]:
>> AFAIK, SSP doesn't support attribute query out of the box, and so SSP
>> doesn't support SAML1 very well.
>
> That would only be an issue if one would under no circumstances just
> include the (unencrypted) attribute assertion in the first place.
> Or if the SP could not process the attribute assertion presented that
> way, insisting on fetching it afterwards via SOAP.
> I would hope that the latter is sufficiently rare (ideally
> non-existent)
I don't think it is rare. AFAIK, the Shibboleth SP (e.g.) will query
<peter....@univie.ac.at> wrote:
> * Tom Scavo <trs...@gmail.com> [2014-01-31 16:46]:
>> AFAIK, SSP doesn't support attribute query out of the box, and so SSP
>> doesn't support SAML1 very well.
>
> That would only be an issue if one would under no circumstances just
> include the (unencrypted) attribute assertion in the first place.
> Or if the SP could not process the attribute assertion presented that
> way, insisting on fetching it afterwards via SOAP.
> I would hope that the latter is sufficiently rare (ideally
> non-existent)
for attributes if it doesn't receive the attributes it needs on the
front channel. This is why we recommend that IdPs NOT insert a SAML2
AttributeService endpoint into their metadata. Doing so causes the SP
to execute a superfluous query and issue a spurious error message to
the user in those cases where the needed attributes aren't pushed in
the first place.
> and the former is a decision for the IdP organistion to
> make. For the attributes we send to SAML1-only SPs we don't care about
> potential exposure to the browser during transit (non-PII).
confirmed my understanding that SSP doesn't support attribute query.
That's fine, I don't see that as a serious omission, but it is a
limitation that deployers have to live with (as you've noted).
Thanks,
Tom
Peter Schober
Jan 31, 2014, 11:26:24 AM1/31/14
to simpleSAMLphp
* Tom Scavo <trs...@gmail.com> [2014-01-31 17:16]:
(the thing being rare) was about SPs that (in other words) could
/only/ process attributes when querying for them via SOAP, but not
then they had been pushed via HTTP POST with the authentication
assertion.
That'd be the only (hopefully hypothetical) case I can think of what
would be a problem with SSP, which can push attributes just fine when
using SAML1 (assuming exposure to the browser is not an issue, which I
often find it not to be).
Let's hope we can forget about SAML1-only SPs, it's 2014 dammit. ;)
-peter
> On Fri, Jan 31, 2014 at 10:58 AM, Peter Schober
> <peter....@univie.ac.at> wrote:
> > * Tom Scavo <trs...@gmail.com> [2014-01-31 16:46]:
> >> AFAIK, SSP doesn't support attribute query out of the box, and so SSP
> >> doesn't support SAML1 very well.
> >
> > That would only be an issue if one would under no circumstances just
> > include the (unencrypted) attribute assertion in the first place.
> > Or if the SP could not process the attribute assertion presented that
> > way, insisting on fetching it afterwards via SOAP.
> > I would hope that the latter is sufficiently rare (ideally
> > non-existent)
>
> I don't think it is rare. AFAIK, the Shibboleth SP (e.g.) will query
> for attributes if it doesn't receive the attributes it needs on the
> front channel. This is why we recommend that IdPs NOT insert a SAML2
> AttributeService endpoint into their metadata. Doing so causes the SP
> to execute a superfluous query and issue a spurious error message to
> the user in those cases where the needed attributes aren't pushed in
> the first place.
That's a different issue though. If you re-read my comment above it
> <peter....@univie.ac.at> wrote:
> > * Tom Scavo <trs...@gmail.com> [2014-01-31 16:46]:
> >> AFAIK, SSP doesn't support attribute query out of the box, and so SSP
> >> doesn't support SAML1 very well.
> >
> > That would only be an issue if one would under no circumstances just
> > include the (unencrypted) attribute assertion in the first place.
> > Or if the SP could not process the attribute assertion presented that
> > way, insisting on fetching it afterwards via SOAP.
> > I would hope that the latter is sufficiently rare (ideally
> > non-existent)
>
> I don't think it is rare. AFAIK, the Shibboleth SP (e.g.) will query
> for attributes if it doesn't receive the attributes it needs on the
> front channel. This is why we recommend that IdPs NOT insert a SAML2
> AttributeService endpoint into their metadata. Doing so causes the SP
> to execute a superfluous query and issue a spurious error message to
> the user in those cases where the needed attributes aren't pushed in
> the first place.
(the thing being rare) was about SPs that (in other words) could
/only/ process attributes when querying for them via SOAP, but not
then they had been pushed via HTTP POST with the authentication
assertion.
That'd be the only (hopefully hypothetical) case I can think of what
would be a problem with SSP, which can push attributes just fine when
using SAML1 (assuming exposure to the browser is not an issue, which I
often find it not to be).
Let's hope we can forget about SAML1-only SPs, it's 2014 dammit. ;)
-peter
Tom Scavo
Jan 31, 2014, 11:51:31 AM1/31/14
to simpleSAMLphp
On Fri, Jan 31, 2014 at 11:26 AM, Peter Schober
<peter....@univie.ac.at> wrote:
>
> Let's hope we can forget about SAML1-only SPs, it's 2014 dammit. ;)
:-)
<peter....@univie.ac.at> wrote:
>
> Let's hope we can forget about SAML1-only SPs, it's 2014 dammit. ;)
This is off topic but there are 14 SAML1-only IdPs and 75 SAML1-only
SPs in the InCommon Federation, so we're not out of the woods yet. In
contrast there are 36 SAML2-only IdPs and 183 SAML2-only SPs.
Cheers,
Tom
Reply all
Reply to author
Forward
0 new messages