Is this a metadata error?

[David Gersic]

>>> On 5/24/2013 at 03:20 PM, "Cantor, Scott" <cantor.2 at osu.edu> wrote: 
>>  Hm. I'll have to plead ignorance here. I don't know if I have, or not, and I
>> don't know where to look. Where would a filter plugin be deployed or
>> defined?
> 
> https://wiki.shibboleth.net/confluence/x/SIG3
> 
> Unless you're on 2.4 or added this plugin from uApprove and installed a rule 
> using the AttributeInMetadata match function, you're not using it.

Ah, ok, that explains it. No, I'm on 2.3.5 here, not 2.4 yet, and I haven't added anything to it. I probably need to start reading up on 2.4 and planning to upgrade, but for the moment I've been ignoring it.


>> What they need is an indication that the authenticated person is a "student"
>> or "employee". These are mutually exclusive in their system.
> 
> Ah, then I think they have a bug because people do not exist in mutually 
> exclusive states.

Agreed. But, sadly, there's not much I can do about somebody else's bugs. And, like it or not, somebody here has selected this vendor to work with, so about all I can do is try to make it work the way they need it to work.


> I would say that one might provision which role somebody is meant to have, 
> and then whatever role is assigned has to match one of the asserted values 
> you give them.
> 
> But the best answer is to use entitlements, and not try and use affiliation 
> at all. That's a much better fit for the problem.

I agree with you, in theory, but the reality of this vendor is that they have to have a single valued assertion of "student" or "employee". The data being fed to them from our identity management system includes this already, so I don't know why they need this from the IdP, but they seem to.


>> ePA is multivalued, and a person could be both "student" and "employee" 
> here. By
>> populating ePPA with the "best" single value of ePA, it seemed to me that
>> having this vendor use ePPA would meet their needs in a way that made the
>> most sense.
> 
> One example of how this breaks: the attribute value you populate shouldn't 
> depend on the application (because affiliations are not an app-specific 
> concept). 

Agreed. I'm not populating ePPA for just this application. Any app that needs a single value can have ePPA. Somewhat less buggy apps can have ePA.


> Now consider you have two apps with this same bug, but in the two 
> cases, the "best" fit for a given student employee isn't the same in both 
> cases.

"Best" I'm defining in the identity system, and populating ePA and ePPA accordingly. If the app disagrees, that's too bad for them. We have existing rules in place for deciding what a person's primary role is between the ideas of "student" and "employee".


>> Looking at the InCommon metadata, it looks like I'm not the only one trying
>> to do something like this with this vendor, other sites are using
>> eduPersonScopedAffiliation, probably for the same reason. I'm not seeing a
>> big difference between an ePPA of "student" vs. an ePSA of
>> "student at niu.edu" really.
> 
> No unscoped version of affiliation really has any use case within a 
> federated system, because without the scope it isn't sufficiently 
> identifying. We really don't expect to see any of them but ePSA in SAML.
> 
> ePSA itself is a scoped version of ePA, meaning it's multi-valued. So it's 
> not at all the same as using ePPA. It is entirely different in the area we're 
> discussing.

Argh. You're right. I just re-read ePSA and it is multivalued. I mis-remembered it being single valued.

Since ePSA is multi-valued, whether I have it or not isn't going to make a difference. I need a single valued "best" view of multi-valued internal data. ePPA seems to be the best available defined attribute in eduPerson for this. I think I've released ePPA to them, and they're not getting it. >From the IdP, where do I look? Or do I need to get them to look at the SP to find out what's going on there?