Getting remoteAddr and cookies into attributes?

[Cantor, Scott]

> Q1) Can we get the client IP address into a (scripted) attribute with no or
> minimal Java code? Is there a reasonable way to pull in p:customObject-
> ref="shibboleth.HttpServletRequest" as in the SPNEGO examples?

As always, that only works for front-channel, so you'd best be sure that's all you ever need. I don't advise depending on that.

But that *is* how to access it...it's mentioned on the ScriptedAttributeDefinition page (as of 3.2 anyway). If you need to expose more than one object, then you have to create a map containing the objects or references to objects you want to expose, define it in Spring wiring, and then reference it via customObjectRef. So you can basically define your own "API" if you like.

> Q2) Can we set an attribute to the value of a specific client cookie? (With
> some sanity checking of the user input, of course.)

What you do in a script is entirely up to you.

> Q3) Is there existing functionality we can leverage to set a new custom
> browser cookie, ideally without any new Java code?

There's a class in the java-support library, net.shibboleth.utilities.java.support.net.CookieManager, and that's an API class. The IdP has a couple of instantiations of it internally, and I have yet to document specifically what beans are acceptable to reuse, but those are fairly safe to rely on, they're in global-system.xml. One is for session cookies, one for persistent. The API takes the cookie name, so it lets multiple pieces of code reuse the general cookie properties that are set, but for different cookies.

> 1) Long-term browser cookie asserting "user X has logged on from this web
> browser before." This could be something stateless like computedId or
> stored in a database.

There are advantages to doing something explicit and using the DataSealer API in terms of control, and advantages to just writing to the Storage API and completely ignoring all the security and storage details, but the latter would really have to be client-side only, so it's sort of like CAS in reverse, it uses a standard API but only works with specific subsets of the available plugins to that API.

> I think #3 is achievable with a combination of scripted attributes and a fork of
> the context-check intercept flow, if we can handle the prerequisites of
> remoteAddr and cookie handling.

I wouldn't call it a fork, it's just a different intercept for a different purpose.

-- Scott