Attribute filter requirement based on client IP-address

[Philip Brusten]

On 7/05/2013 01:34, Cantor, Scott wrote:
> On 5/6/13 3:56 PM, "Philip Brusten" <philip.brusten at icts.kuleuven.be>
> wrote:
>
>> Well I didn't fully explained... Of course you cannot add attributes in
>> the attribute-filter, but I think the filter would be a better place to
>> implement this IP-based logic. Because basically what you are doing is
>> filtering on the principal's attributes based on the context, which in
>> this case is an IP-address.
> Yes, but the code they wrote *creates* attributes based on address, it
> doesn't filter based on it. You can't do what they did in a filter.
You're right, but I prefer to manage the attribute values through our 
provisioning system. From a user support point of view this makes a lot 
more sence , since you can show *all* the rights (e.g. entitlements) an 
account has from your backend directory. Adding additional attribute 
logic in the attribute-resolver is a bit confusing I believe, but that's 
subjective of course...
>> Is this a yes for 'am I right' or for  'yes, you can get the IP-address
> >from the ShibbolethFilteringContext' :-)
>
> Yes, you can get it. I don't speak that Javascript dialog very well, but
> in Java, you get the inbound transport object from:
>
> ShibbolethFilteringContext.getAttributeRequestContext().getInboundMessageTr
> ansport()
>
> Then do:
>
>
> HttpServletRequest httpRequest =
> 	((HttpServletRequestAdapter)inTransport).getWrappedRequest();
>
>
Thanks for pointing this out

Philip