activationCondition IPRangePredicate

[Cantor, Scott]

I think the examples are tripping over a decision to use Iterable<IPRange> instead of Collection<IPRange> for the IPRangePredicate property. Don't know if that was deliberate, a mistake by me, whatever. May be troublesome to fix without creating ambiguous conflicts, but I would file a bug if you want it to get cleaned up, at the least a separate property could be added to handle the alternate type.

>    We are running the IdP behind a loadbalancer which injects the original 
>    IP in a custom HTTP-header, so we will need to evaluate that custom 
>    header instead of request.getRemoteAddr().
>    This would be a nice add-on to this predicate function.

Our position is that that needs to be handled in your container. Otherwise we would have to implement it in every possible place, that's just not practical.

Most containers either support this out of the box, have add-on filters that work, or it's easy to write one.

> Is there an easy way to import that list from a properties-file?

Only if we get the conversion / type fixed so a string value will work. You can't get multiple <list> bean values populated from a single property, not without the expression syntax.

-- Scott