[Shib-Users] Accessing a SP Entity ID into a Script

[Ken Hammer]

 Hello

 We're pulling attributes from a LDAP connection, then manipulating them via a Java Script
to populate the eduPersonEntitlement attribute. Of course, this attribute could be potentially
different for each SP. Therefore, we'd like to dynamically create the 'Entitlement attributes based
on the SP asking for them.
 Being  a novice to Java Scipt, I've figured out how to get the LDAP attributes into
my script, so they can be massaged in different ways, but I can't seem to figure out how to get the
SP Entity ID to the script.
 I have poured through as much of the documentation on the wiki site as I can, as well as done
several searches on Google for some help, but no joy is to be found.
 Can anybody offer some help, or point me a direction where I may find enlightenment on this?

Thanks!

-- 
Ken Hammer
Web/DBA Team
University Of Michigan

[Greg Haverkamp]

On Jul 17, 2009, at 12:28 PM, Ken Hammer wrote:

 We're pulling attributes from a LDAP connection, then manipulating them via a Java Script
to populate the eduPersonEntitlement attribute. Of course, this attribute could be potentially
different for each SP. Therefore, we'd like to dynamically create the 'Entitlement attributes based
on the SP asking for them.
 Being  a novice to Java Scipt, I've figured out how to get the LDAP attributes into
my script, so they can be massaged in different ways, but I can't seem to figure out how to get the
SP Entity ID to the script.

Even if you can get at that information (I don't think you can, but I'm sure someone more authoritative will respond), it would be far easier and more flexible to simply create the various forms of entitlement attributes you need and then release them appropriately via attribute filters based on SP.

Greg

[Chad La Joie]

The ePE really shouldn't change depending on the SP. Either the person
has the entitlement or they don't. If you want to restrict which SPs
see which values that's the job of the attribute filter. I would not
recommend blurring that distinction, it could have unforeseen consequences.

Now, to specifically answer your question, you can get access to the SP
through the request context - requestContext.getPeerEntityId()

--
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

[Scott Cantor]

Greg Haverkamp wrote on 2009-07-17:
> Even if you can get at that information (I don't think you can, but I'm
sure
> someone more authoritative will respond), it would be far easier and more
> flexible to simply create the various forms of entitlement attributes you
> need and then release them appropriately via attribute filters based on
SP.

I would agree, but in terms of a vague answer, the SP is the "requester" and
should be available via the request context made available to the script.
Don't know more than that.

-- Scott

[Chad La Joie]

Oh, I'll also note, I'll be putting up the javadocs for the IdP,
finally. I didn't have a space for them on the shib site initially and
then it just fell off the end of my list. I'll post the link once
they're there.

[Ken Hammer]

Chad La Joie wrote:
> The ePE really shouldn't change depending on the SP. Either the
> person has the entitlement or they don't. If you want to restrict
> which SPs see which values that's the job of the attribute filter. I
> would not recommend blurring that distinction, it could have
> unforeseen consequences.
>
> Now, to specifically answer your question, you can get access to the
> SP through the request context - requestContext.getPeerEntityId()
>

Wow, thanks to all for the quick replies, it is really appreciated!

I have a couple of more questions, if folks don't mind. On the
statement that was made "The ePE really shouldn't change depending on
the SP",
perhaps I've really misunderstood the ePE definition. I was under the
impression that different SP's could require different ePEs. I'm using
this description
(from
http://www.incommonfederation.org/attributesummary.html#eduPersonEntitlement)
which says that
it can be "Muliple values, each a URI, representing a license,
permission, right, etc." ?
Or from the examples from
(http://middleware.internet2.edu/eduperson/docs/internet2-mace-dir-eduperson-200806.html#eduPersonEntitlement)
which show some
examples like:

Examples:

eduPersonEntitlement: http://xstor.com/contracts/HEd123
eduPersonEntitlement: urn:mace:washington.edu:confocalMicroscope

Again, I apologize if I am misunderstanding the purpose of the
eduPersonEntitilement attribute.

Oh, and when I use the requestContext.getPeerEntity() in my script, it
returns a "null" Did I need to import a specific package
or is there some other type of JS voodoo I need to preform to get the value?

Thanks again.

"An object in possession seldom retains the same charm that it had in pursuit." Pliny the Younger

[Chad La Joie]

Ken Hammer wrote:
> I have a couple of more questions, if folks don't mind. On the statement
> that was made "The ePE really shouldn't change depending on the SP",
> perhaps I've really misunderstood the ePE definition. I was under the
> impression that different SP's could require different ePEs.

An SP may have expect different entitlements, but that's different than
whether the user has them or not. A user may be entitled (and thus have
the entitlements for) SP A, B, C. That's true whether the user visits A
or B or C.. or D, E, and F. The entitlements the user posses, in their
identity record, doesn't change. Now, you my choose to only release A's
entitlements to SP A, but, again, that doesn't mean the user loses the
entitlements possessed for B and C.

> Oh, and when I use the requestContext.getPeerEntity() in my script, it
> returns a "null" Did I need to import a specific package
> or is there some other type of JS voodoo I need to preform to get the
> value?

Try getInboundMessageIssuer, there are some inconsistencies about which
property gets populated. They need to be cleaned up in the code.

[Ken Hammer]

Chad La Joie wrote:

Ken Hammer wrote:

I have a couple of more questions, if folks don't mind. On the statement that was made "The ePE really shouldn't change depending on the SP",
perhaps I've really misunderstood the ePE definition. I was under the impression that different SP's could require different ePEs.

An SP may have expect different entitlements, but that's different than whether the user has them or not.  A user may be entitled (and thus have the entitlements for) SP A, B, C.  That's true whether the user visits A or B or C..  or D, E, and F.  The entitlements the user posses, in their identity record, doesn't change.  Now, you my choose to only release A's entitlements to SP A, but, again, that doesn't mean the user loses the entitlements possessed for B and C.

Oh, and when I use the requestContext.getPeerEntity() in my script, it returns a "null" Did I need to import a specific package
or is there some other type of JS voodoo I need to preform to get the value?

Try getInboundMessageIssuer, there are some inconsistencies about which property gets populated.  They need to be cleaned up in the code.

 Thanks Chad, the getInboundMessageIssuer did the trick. And thanks for the explanation on the ePE.

[Ken Hammer]

Chad La Joie wrote:
>
> An SP may have expect different entitlements, but that's different
> than whether the user has them or not. A user may be entitled (and
> thus have the entitlements for) SP A, B, C. That's true whether the
> user visits A or B or C.. or D, E, and F. The entitlements the user
> posses, in their identity record, doesn't change. Now, you my choose
> to only release A's entitlements to SP A, but, again, that doesn't
> mean the user loses the entitlements possessed for B and C.
>

OK. Maybe I don't get the eduPersonEntitlement explanation, like I
thought. :).

We're going to use the Java Script to dynamically populate the
eduPersonEntitlement based on the SP requesting said attributes. I
understand
that we can control the attributes that are being released to a SP. I
also understand that a user entitlement doesn't change.

So, for instance, SP A requires that the ePE for a user be
"www.umich.edu/member". SP B requires that the ePE be
"urn:mace:dept:status", and so on. Since, initially at least, we don't
want to modify a persons LDAP entry to add this
attribute, or store it in a separate repository (Oracle, MySQL, etc), we
were going to create the required ePE dynamically via
a Java Script (hence the need for the SP ID). Is there something
inherently wrong with this strategy?

We understand that ultimately this strategy will probably become
unwieldy to maintain, (1000s of users going to 1000s of
SPs), but initially, we'd like to try and generate this attribute on the
fly.

Thank you very much for taking the time to read and/or respond to this
message.

>> Oh, and when I use the requestContext.getPeerEntity() in my script,
>> it returns a "null" Did I need to import a specific package
>> or is there some other type of JS voodoo I need to preform to get the
>> value?
>
> Try getInboundMessageIssuer, there are some inconsistencies about
> which property gets populated. They need to be cleaned up in the code.

--

[Scott Cantor]

Ken Hammer wrote on 2009-07-17:
> OK. Maybe I don't get the eduPersonEntitlement explanation, like I
> thought. :).

The point is that it's not using the system's various pieces as intended if
you dynamically generate the entitlements with the SP in mind. An example of
why is that if you later moved the generation of them out of band and into a
directory entry or database, you then have to create all the same filter
policies that we're suggesting you create now.

Instead, populate the entitlements as they are according to policy and
filter the values as needed. That will work unchanged if you modify the
source of the values.

> We understand that ultimately this strategy will probably become
> unwieldy to maintain, (1000s of users going to 1000s of SPs), but
> initially, we'd like to try and generate this attribute on the fly.

That's why we're just suggesting dividing the work up as it eventually would
be divided.

-- Scott

[Ken Hammer]

Scott Cantor wrote:

>
> Instead, populate the entitlements as they are according to policy and
> filter the values as needed. That will work unchanged if you modify the
> source of the values.
>
>
>

Can you point me to specific documentation on how this is done. One of
the reasons that we wanted
to create the ePE value on the fly is because we wanted to present the
SP only the Entitlement it wanted, not
all the Entitlements a person had.
I view the Entitlements as a "hash" of all the entitlements a person
may have. Instead of sending
the entire "hash" to the SP, I'm looking to send just the specific
Entitlement the SP wants.

Once again I appreciate the responses to my questions.

[Jim Fox]

>>
>> Instead, populate the entitlements as they are according to policy and
>> filter the values as needed. That will work unchanged if you modify the
>> source of the values.
>>
> Can you point me to specific documentation on how this is done. One of
> the reasons that we wanted
> to create the ePE value on the fly is because we wanted to present the
> SP only the Entitlement it wanted, not
> all the Entitlements a person had.
> I view the Entitlements as a "hash" of all the entitlements a person
> may have. Instead of sending
> the entire "hash" to the SP, I'm looking to send just the specific
> Entitlement the SP wants.
>

Often the easiest way to do this is to define separate attributes
for each of the different entitlements. Each produces an
eduPersonEntitlement, but has a different AttributeDefinition id.

In your filter just release specific entitlements, by id, to your
varous SPs. This way you don't have to worry about value matching,
and can usually release all values.

Jim

[Scott Cantor]

Ken Hammer wrote on 2009-07-20:
>> Can you point me to specific documentation on how this is done.

The wiki includes material on release filtering in the section on adding
attributes to the IdP. Jim's idea is a good one for optimizing that.

> One of
> the reasons that we wanted
> to create the ePE value on the fly is because we wanted to present the
> SP only the Entitlement it wanted, not all the Entitlements a person had.

Right, the normal way to do that is with the filtering layer, not the
resolver.

-- Scott

[Ken Hammer]

 Thanks to all for the help and the pointers. I will investigate your suggestions.