IBM Security Verify

 View Only
Expand all | Collapse all

Custom header and transformation - (Active Directory Attribute)

  • 1.  Custom header and transformation - (Active Directory Attribute)

    Posted Thu May 26, 2022 03:45 AM
    We have a federated active directory on version 10.0.0.2. We see the users in Policy Administration, but we don't have an attribute that we can use as user id other than the user principal name (which is a mail address). The iv-user therefore comes in as firstname.lastname@domain.com.

    How can we define a custom header, lets says ABC_USER, which has the value firstname.lastname@domain.com? We also need to transform this header value, so that it only contains the firstname.lastname and the domain name is dropped? I am aware that the value for iv-user cannot be changed, so we are trying to insert a custom header, which could be consumed by the application.

    I have gone through some of the documentation for this, but the examples are lacking.

    ------------------------------
    Giriraj Dave
    ------------------------------


  • 2.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Thu May 26, 2022 04:06 AM
    Hi Giriraj,

    If your connection from AD was a federation (SAML etc.) connection then it would be relatively simple to create an additional attribute in the credential using the SP JavaScript mapping rule.  However, looks like your Active Directory is a federated directory... with Verify Access reading it directly over LDAPS.

    In that case, I don't think there is an opportunity to perform any attribute manipulation during the login process... so, unless there is a suitable attribute already in AD user record, you'd have to split this into two actions:
    1) Add an HTTP header using the user principal - this can be done with HTTP Tag Value or in configuration file
    2) Use an XSLT HTTP Transformation Rule on the response to modify the header value (remove the domain suffix).

    For (1), use the [header-names] stanza - that's the easiest approach.  For example, use this line:
    credattr{AZN_CRED_PRINCIPAL_NAME} = X-Principal
    To add X-Principal header.​
    If you want to only send to a single junction, add an extended attribute to the junction object with:
    name: HTTP-Tag-Value
    value: AZN_CRED_PRINCIPAL_NAME=X-Principal

    For (2), you need to write an XSLT rule.  This can be tricky but there are examples here:
    https://github.com/IBM-Security/isam-support/tree/master/config-example/webseal/http-transformations/response
    This one looks close to what you need:
    https://github.com/IBM-Security/isam-support/blob/master/config-example/webseal/http-transformations/response/response-modify-header.xslt

    I hope this helps.

    Jon.


    ------------------------------
    Jon Harry
    Senior Technical Sales Enablement Specialist
    Identity and Access Management
    IBM Technology, Worldwide
    ------------------------------

    Original Message


  • 3.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Thu May 26, 2022 12:14 PM
    Hi Jon, thanks very much for your reply and time. I put in the credattr{AZN_CRED_PRINCIPAL_NAME} = X-Principal and now I see that header in the backend. Since we use WebSphere as the backend, I am able to use the snoop servlet to see what's being received.

    Two really dumb questions:

    1) I believe the answer to this would be a resounding no, but I will still ask, can we name our custom header as iv-user? This is coming from our appdev team, the reason being so that they won't have to make any changes in the backend. They would have to make changes to use "x-principal"

    2) You mentioned earlier that we need to use the XSLT Transformation Rule on the response...when I go to Web -> HTTP Transformation and try and create a new file, would that be of Template "Request" or "Response"? I thought earlier that we would have to modify the request header and not response? 

    Also, yes, you are correct, we just have AD as the federated directory with SVA directly accessing it - I also have a minor question around it. For the existing domain, we have a TDI assembly copying internal users from AD to IBM SDS. If we go the federated directory route for the new domain, we can avoid TDI altogether? Would that be a correct statement?

    Thanks again for your help. I will try out the XSLT thing (we don't have any experience around it)...will let you know how that goes.

    ------------------------------
    Giriraj Dave
    ------------------------------

    Original Message


  • 4.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Fri May 27, 2022 09:18 AM
    Hi Giriraj,

    >> can we name our custom header as iv-user?
    You can't override the iv-user header.  I'm not even sure you can modify it with transformation rules. @Nick Lloyd will know.

    >> You mentioned earlier that we need to use the XSLT Transformation Rule on the response...when I go to Web -> HTTP Transformation and try and create a new file, would that be of Template "Request" or "Response"? I thought earlier that we would have to modify the request header and not response?
     I was wrong.  You would need to create a request template to modify the request... since you want to add/change a header in the request going to junction.  Not sure how I confused myself on that.

    >>  If we go the federated directory route for the new domain, we can avoid TDI altogether? Would that be a correct statement?
    If you set up AD as a federated directory *and* enable "basic users", you wouldn't need to use TDI.  When using basic users, there's no need to perform the "import" operation on users to make them visible to Verify Access - the native user object is read directly from AD.  Note that groups you want to use for access control still need to be imported... but usually that is a shorter and mostly static set.

    Jon.
    ​​​

    ------------------------------
    Jon Harry
    Senior Technical Sales Enablement Specialist
    Identity and Access Management
    IBM Technology, Worldwide
    ------------------------------

    Original Message


  • 5.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Fri May 27, 2022 10:02 AM
    It is not possible to modify the headers and cookies inserted by the Reverse Proxy.  See https://www.ibm.com/docs/en/sva/10.0.3?topic=junctions-http-transformations for details.

    Note:
    1. It is not possible to modify the body of the request or response. Similarly, you cannot modify cookies or headers that are inserted by WebSEAL. For example, the Host, iv-user and iv-creds junction headers.


    ------------------------------
    Nick
    IBM Security Verify Customer Support
    ------------------------------

    Original Message


  • 6.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Sun May 29, 2022 11:37 AM
    Hi @Nick Lloyd and @Jon Harry, what we are trying to achieve, is that even possible?

    I fully understand that we cannot modify iv-user, however, as Jon mentioned, I added the below to our config :

    credattr{AZN_CRED_PRINCIPAL_NAME} = minnetonka

    I see the "minnetonka" header in the snoop servlet, which has the value of username, but is it possible to now manipulate "minnetonka" to drop the domain name from user name and just have "firstname.lastname" instead of "firstname.lastname@domain.com" and have that passed to backed app?



    I have gone through several articles and still cannot find anything that's suitable to our problem.
    ​​​​

    ------------------------------
    Giriraj Dave
    ------------------------------

    Original Message


  • 7.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Mon May 30, 2022 02:53 AM
    Hi,

    The only way I could think of to be able to manipulate that value and be able to use iv-user header would be to manage the authentication through an infomap. Doing so, you can create the session with any mapped user-id you like and as it would be the principal name of the session use the built-in junction option to insert iv-user in the http header,

    Regards

    ------------------------------
    Cedric Servais
    ------------------------------

    Original Message


  • 8.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Mon May 30, 2022 10:02 PM
    Hi Cedric, introducing imfomap is like changing a whole lot to the existing configurations. We want to make the minimal changes required, since we have been in Production with ISAM/SVA since several years (with existing config).

    Unfortunately, the new Active Directory domain would be managed by an agency external to us, and there is no user attribute in there that's just firstname.lastname (unlike our existing AD).

    While iv-user value cannot be modified, I was hoping that the custom header "x-principal" - which would be the same value as iv-user (Mail Address) to be able to be edited (so that we could drop the domain name from "x-principal"). The application probably could be modified to use "x-principal" instead of iv-user:

    credattr{AZN_CRED_PRINCIPAL_NAME} = x-principal

    I was thinking it could be achieved using HTTPTransformation as Jon mentioned earlier, but I cannot find any good examples and nothing that I have tried so far has worked. I was thinking that someone on the forum (who had to go through a similar challenge) could help me.

    ------------------------------
    Giriraj Dave
    ------------------------------

    Original Message


  • 9.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Tue May 31, 2022 01:08 AM

    You can absolutely do this with a HTTP transformation rule. I've written one to hopefully show you how. I've tested this on my local environment and it works as documented:

    There are comments in the XSL that describe how to configure it. I modified AZN_CRED_PRINCIPAL_NAME but you could do it to any attribute in the ISVA session credential. Also I believe that the "POP" method of HTTP transformation configuration is required in order to ensure that credential is populated with authenticated user attributes before the HTTP transformation runs. Again all this is documented in comments in the rule text below.

    Regards,

    Shane.

    <?xml version="1.0" encoding="UTF-8"?>

    <xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" version="1.0">

     <!--Firstly, strip any space elements -->

     <xsl:strip-space elements="*" />

     <!--

     Used to set a junction header "myusername" using a value originating (but potentially modified) from another 

     ISAM credential attribute (in this case AZN_CRED_PRINCIPAL_NAME). 

     


     Load this file as a http transformation rule with name "myxform.xsl". Configure in webseal config file:

     


     [http-transformations]

     myxform = myxform.xsl

     


     [http-transformations:myxform]

     # This can be any attribute - in this case I'm going to modify the username to strip of anything after @

     cred-attr-name = AZN_CRED_PRINCIPAL_NAME

     


     You also must use the POP method of triggering http transformations so that the credential attributes

     are available to the transformation rule.

     


     pop create xformpop 

     pop modify xformpop set attribute HTTPTransformation Request=myxform

     pop attach /WebSEAL/localhost-default/myjct xformpop

     


     -->

     <xsl:template match="/"> 

     <xsl:variable name="original" select="//Credential/Attributes/Attribute[@name='AZN_CRED_PRINCIPAL_NAME']" />

     


     <xsl:variable name="final">

     <xsl:choose>

     <xsl:when test="contains($original, '@')"><xsl:value-of select="substring-before($original, '@')" /></xsl:when>

     <xsl:otherwise><xsl:value-of select="$original" /></xsl:otherwise>

     </xsl:choose>

     </xsl:variable>

     <!--

     This is the actual request change that inserts the value above into the header myusername

     -->

     <HTTPRequestChange>

     <Header name="myusername" action="update"><xsl:value-of select="$final" /></Header>

     </HTTPRequestChange>

     </xsl:template>

     


    </xsl:stylesheet>



    ------------------------------
    Shane Weeden
    IBM
    ------------------------------

    Original Message


  • 10.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Tue May 31, 2022 01:15 AM

    Further to above example, you *can* make it work for iv-user as well. It's a little more configuration, but it is possible. Here's how:

    1. You MUST NOT configure the junction to send any identity headers (i.e. no iv-user, etc). 

    2. In addition to above configuration, add something like this in the WebSEAL configuration file:

    [header-names]

     httphdr{myusername} = iv-user
    If both those things are done, then you should see iv-user populated with the value that was created for myusername in the transformation rule.



    ------------------------------
    Shane Weeden
    IBM
    ------------------------------

    Original Message


  • 11.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Mon June 06, 2022 08:43 AM
    Hi Shane, thank you so much for your reply. Your solution works fine (we were also able to spoof the iv-user value as well). Thanks to Nick Lloyd and Jon Harry for their inputs...thanks to Cedric and Matt as well!

    Just a few things for someone's reference (if they ever have the same problem as us).

    1) When we configure the junctions, we traditionally supply the highlighted below:

    I had to uncheck the "IV-USER" and "IV-USER-L" for this to work (as suggested in your post).

    I also noticed that if a user is part of iv-admin group, it messes a few things. For example, my account was part of iv-admin and I would never see the custom header "minnetonka" (just wanted a funny name to make my day a little delightful ;)) and iv-user would show "NOT_FOUND".

    Again, thanks for the excellent support on this forum.

    ------------------------------
    Giriraj Dave
    ------------------------------

    Original Message


  • 12.  RE: Custom header and transformation - (Active Directory Attribute)

    Posted Mon June 06, 2022 10:14 AM
    Excellent - glad it worked out for you!

    ------------------------------
    Shane Weeden
    IBM
    ------------------------------

    Original Message


  • 13.  RE: Custom header and transformation - (Active Directory Attribute)

    IBM Champion
    Posted Tue May 31, 2022 08:28 AM
    I like Shane's solution above.  This may be another potential solution for you.  If you use the user name mapping module, you can insert attributes into the session from there.  Because the user name mapping module uses XSLT, you could create the attribute value you need, add to the session, and then use that session attribute as an HTTP-Tag-Value extended attribute on your junctions, or in the webseald config file as Shane described.

    Some examples:
    https://github.com/IBM-Security/isam-support/blob/master/config-example/webseal/user-name-mapping/realm-usermapping.xsl

    Documentation:
    https://www.ibm.com/docs/en/sva/10.0.3?topic=aum-user-mapping-rules-evaluator

    For example, you can insert the mTLS client cert DN into the session attributes as such:
    <attribute name="tagvalue_certSubject"><xsl:value-of select="stsuuser:Attribute[@name='x509.subject_dn']/stsuuser:Value"/></attribute>

    Then configure the junction to pass tagvalue_certSubject as an HTTP header, say cert-subject.  I only mention this specific example because I've done it, but I believe it should be easy enough to do what you are attempting using a similar fashion.  The downside to this is it will fire for all authentications, whereas the transform rule Shane mentioned could be applied to specific junctions.  I'm not sure of the performance hit on one solution versus the other, if performance is a concern, but the user name mapping module would only fire during authentication, whereas the transform rule would fire on each request.

    Anyway, just thought I would throw my hat into the ring here (plus I'm always interested in hearing pros/cons of things I am doing).  If you are using the user name mapping module, it might be another potential way you can achieve what you are trying to do.

    PS:  One thing I was wondering with Shane's iv-cred httphdr solution was if you could use HTTP-Tag-Value to insert the iv-user attribute, considering -c iv_user is not set on the junction properties.  If so, that would allow you to override iv-user on specific applications, otherwise if you needed to only do this for specific applications you of course would end up having to do a custom http header.  Good conversation here nonetheless, I wasn't aware iv-user could be overridden as Shane described.

    ------------------------------
    Matt Jenkins
    ------------------------------

    Original Message