Generating SAML attributes and calculations in variable assignments

I just tried to test that out in my environment, and it looks like the command

sha256

is not available within the VPE (seems that some of the custom commands are only available through the iRules). I think because of that, if you wanted a SHA256 hash, you'd need to use an iRule event and do it in an iRule.

Another option might be to use a hex-encoding of an attribute, which you can do in the VPE itself. You could use a variable assign with the value:

binary scan [mcget session.ad.last.attr.sAMAccountName] H* encstr
return $encstr

Hi Michael,

 

thank you for your help. I'm fine with using something else then sha256. I've just tried to replace the custom expression in my variable assignment by your code. But if I do this the session variable is not present, sane as far sha256. I'm running BIG-IP 11.6.0 Build 5.0.429 Hotfix HF5. Maybe I need a later version?

 

If I may add, can you clarify "privacy-preserving"?

 

SHA is a hashing algorithm so whatever you get from that operation isn't going to be reversible on the other side. Hex-encoding is reversible, but it's not really "encrypted" so no real security there.

 

I use the following:

 

 

The APM log shows the following error "Rule evaluation failed with error: can't read "encstr": no such variable". The variable is not visible at all.

 

Kevin, I'm trying to implement attributes as described here:

 

https://www.incommon.org/federation/attributesummary.html

 

In the final version of the assignement I will add information about the SP.

 

I'm assuming you're referring to eduPersonTargetedID. The definition uses the word "opaque", which doesn't mean encrypted. The definition does imply, however, that the value should reveal no information about the user. That rules out hex-encoding. A hash could work here, but the definition also implies that it should not rely on the username, nor necessarily change when the username changes, which a hash surely would.

It's a little vague as to how the value is actually constructed, and just Googling around I see a few different variations of formatting. Are you certain that a SHA256 hash will work here, per the InCommon specification?

As for the VPE assignment, you need a semicolon between the commands:

binary scan [mcget session.ad.last.attr.sAMAccountName] H* encstr; return $encstr

Dear All, adding the ";" did do the trick.

 

As far as I understand the definition of eduPersonTargetedID it is an attribute which is unique for a user to each service provide and is purposely obfuscated so that the user's personal details are not provided. They can be used to provide both a unique identifier for the user and enable service providers to create personalised services. Thus using a fixed attribute of the user (like the email adress) and adding some prefix/suffix per SP to it should do the trick.

 

If I can't use SHA256 directly in the variable assignment, how could I use an irule to add the argument to my SAML response?

 

Do this:

1. Add an iRule event agent to the visual policy.

2. Add an iRule to the VIP:

   when ACCESS_POLICY_AGENT_EVENT {
       ACCESS::session data set "session.user.MyPersistentNameID" [b64encode [sha256 [ACCESS::session data get "session.ad.last.attr.mail"]]]
   }
   

sha256 is going to produce a binary value, probably not exactly what you want, so base64-encoding that makes it at least portable. You could also actually hex-encode the sha256 output to produce a slightly more palatable hexadecimal product:

binary scan [sha256 [ACCESS::session data get "session.ad.last.attr.mail"]] H* encstr
ACCESS::session data set "session.user.MyPersistentNameID" $encstr

Hi,

if binary scan work in variable assign, did you try:

session.user.mytestvar = binary scan [sha256 [mcget session.ad.last.attr.mail]] w1 encstr; return $encstr

In VPE, create a new box "iRule Event" to raise ACCESS_POLICY_AGENT_EVENT. In the ID, you can use sha256 (ID will not be used in the irule for now but may be useful if you need to add one other irule event later).

 

Add the irule provided by kevin and enable it in the virtual server.

 

I guess it is the later to make sure that each SP receives a different value for "eduPersonTargetedID"

 

I'd imagine this value would be something that you'd create dynamically. At the very least you could simply encode the username for simple opacity, or actually pre-compute some identifier and store in the directory. In either case this can all be handled in real time within a single IdP instance.