Skip to Content.
Sympa Menu

edugain-discuss - [eduGAIN-discuss] RequestedAttribute "in the field"

edugain-discuss AT lists.geant.org

Subject: An open discussion list for topics related to the eduGAIN interfederation service.

List archive

[eduGAIN-discuss] RequestedAttribute "in the field"


Chronological Thread 
  • From: Andy Bennett <andyjpb AT knodium.com>
  • To: <edugain-discuss AT geant.net>
  • Subject: [eduGAIN-discuss] RequestedAttribute "in the field"
  • Date: Sat, 3 May 2014 17:55:35 +0100
  • Authentication-results: spf=none (sender IP is ) smtp.mailfrom=andyjpb AT knodium.com;
  • List-archive: <https://mail.geant.net/mailman/private/edugain-discuss/>
  • List-id: eduGAIN discussion list <edugain-discuss.geant.net>

Hi,

I'm representing Knodium who are a Service Provider in the UK
Federation. Our metadata has been exported to eduGAIN since November 2013.

I'm somewhat late to the eduGAIN-discuss party but I've recently been
having RequestedAttribute based drama and I've read up on the "SPs with
no attribute requirements (or so it seems)" thread in the archives.

I'd like to pitch in with our experience over the last few weeks which
is mainly operational in nature. I've been encouraged to post here to
open up a wider discussion. I've not been able to determine if what we
are trying to do is pushing the envelope or whether there are others in
eduGAIN trying to achieve a similar thing.



As you may be aware, we do not currently make use of RequestedAttribute
in the UK Federation. We've just started working with a couple of
institutions with IDPs in 2 separate European federations that are part
of eduGAIN. These federations do make use of RequestedAttribute.

We (Knodium) were asked to provide RequestedAttribute data and made an
attempt to do so. We were advised to avoid setting isRequired="true" on
anything as it was suggested that some IDPs will refuse to send anything
at all if they are unable to release any single required attribute.


The problem for us is that the two federations interpret the semantics
of RequestedAttribute slightly differently and in mutually conflicting ways.

One federation's IDPs will only release an attribute if it is happy to
do so *AND* it appears in our list of RequestedAttributes. If we ask for
nothing then we get nothing.

The other federation's IDPs will always release everything we ask for
but the federation will only "enable" us if our list of
RequestedAttributes satisfies their policy.

Neither Federation seems to processes isRequired.


Our service is able to use a wide range of attributes and so this is
what we included in the metadata but we will still work if IDPs send us
as little as EPTID (which we absolutely require). We would like to
receive as much as we can mutually agree on in order to provide the
friendliest experience to the end user.




I don't think it's particularly useful to have a debate about what the
correct behaviour is as the operational reality is that there are
differing implementations. I'm more interested in a discussion about how
we should move forward in the medium term and how policy might be
negotiated over a longer timescale. For the short term I have submitted
another version of our metadata which includes a much more minimal
RequestedAttribute list and this should be deployed soon: we're trading
off working-at-all in one federation with
not-providing-the-richest-possible-experience in the other.




Regards,
@ndy

--
andyjpb AT knodium.com
http://www.knodium.com/






Archive powered by MHonArc 2.6.19.

Top of Page