> I wonder if the SP would be able to bend slightly by prepended all
their group names with some string such that they do form a valid URN
they're unlikely to do this Nick.
ePSA has too strict a vocab and ePA requires URL/URN. What we're
seeing is the application of shibboleth to "working systems",
basically replacing username/password combos with attributes/values
and eduPerson can't seem to cope with this "legacy" situation. Was
hoping to avoid a custom attribute as their SP might not pass it on
(it's not an I2 sp).
Can't see why an attribute such as ePA can't have a specific "profile"
that allows whatever values an SP/IdP are willing to use when in the
context of that profile, other than SP software that rigorously
applies the eduperson spec to those values.
Alistair
--------------
mov eax,1
mov ebx,0
int 80h
On 25 Nov 2008, at 11:27, Nick Howes wrote:
> Ah, if the values are already chosen then that makes things a little
> difficult. I wonder if the SP would be able to bend slightly by
> prepended all their group names with some string such that they do
> form a valid URN (eg "urn:some-sp-entitlement:"), and you can then
> generate the same in the attribute resolver.
>
> Referring back to your initial post - if you did decide to release
> some custom attribute, I think SPs would safely ignore it if it
> didn't know what it was. But using the standard attributes is
> probably better if possible.
>
>
> Alistair Young wrote:
>> thanks Nick,
>>
>> must take those blinkers off, didn't see that! Although we don't
>> want URL/URN, we just want to assert a membership value of an SP
>> defined group, i.e. a word, e.g. "resource-x". The SP defines the
>> groups and doesn't use URL/URN, hence ePSA which uses simple
>> values, although restricted by the spec.
>>
>> Alistair
>>
>> --------------
>> mov eax,1
>> mov ebx,0
>> int 80h
>>
>> On 25 Nov 2008, at 10:58, Nick Howes wrote:
>>
>>> As I understand it, this is what eduPersonEntitlement is for. It
>>> can contain any values that an IdP and SP want to agree on. Film &
>>> Sound Online has an entitlement value that indicates a user can
>>> access its restricted medical content, which we only release for
>>> users in our medical departments.
>>>
>>> Nick
>>>
>>> Alistair Young wrote:
>>>> Hi folks,
>>>>
>>>> are there any best practices for the use of ePSA? The specs have
>>>> a tightly controlled vocabulary which applies in the context of
>>>> the IdP. However, we're seeing a use case where we'd like to pass
>>>> values that are in the context of a mutually agreed affiliation
>>>> between the IdP and SP. Basically, the SP would be defining finer
>>>> grained affiliations based on resources held by the SP and the
>>>> IdP would assert accordingly, e.g. "member allowed to access
>>>> Resource X". AFAIK OpenAthens allows you to do this using ePSA,
>>>> which can be used to contain user roles that are Athens
>>>> permission sets, which are obviously outside the controlled
>>>> vocabulary of ePSA.
>>>>
>>>> The other way is to define a completely new attribute (OpenAthens
>>>> again, userRole) but some SPs might not like that. I don't see a
>>>> problem using ePSA to transport custom affiliations but just
>>>> thought I'd check with those who know these things.
>>>>
>>>> thanks,
>>>>
>>>> Alistair
>>>>
>>>>
>>>> --------------
>>>> mov eax,1
>>>> mov ebx,0
>>>> int 80h
>>>
>
|