[ISAM 9 docker] Extended attributes forwarding to backend servers

5. RE: [ISAM 9 docker] Extended attributes forwarding to backend servers

Like

Laurent Carrasco

Posted Thu July 25, 2019 08:38 AM

Hi Robert,

Your example is fine if you want to use User Mapping module, and I'm not sure I want to use it. If I understand correctly, the attributes added via User Mapping module are added to the iv-creds blob. If that's not the case, then where can we find the added attributes on the backend ?

And the problem with iv-creds is that we have not managed to use the new authorization API without policy and authorization servers. If anyone got this new API working, I am interested.

And that is why I am looking for another way to forward attributes to the backend. HTTP-Tag-Value looks fine, but I don't know what attributes are available for forwarding.

------------------------------
Laurent Carrasco
------------------------------

Original Message

Original Message:
Sent: Thu July 25, 2019 07:13 AM
From: Robert Trotter
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The attributes you can use in the attribute mapping module are listed here (issuer_db and serial_number are both listed)
https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/reference/ref_user_mapping_vld_cert_attr.html

This really tripped me up at first -- if you don't specify an attribute in the XSL - then it wont be populated into the trace. There's a tiny line in the doco stating that.

Here's a really simple example I did a couple of years ago. You can see me taking an attribute and then adding it as a tagvalue_* attribute: https://www.robtrotter.com/tech/isam/isam-authenticated-user-mapping

------------------------------
Robert Trotter

Original Message:
Sent: Thu July 25, 2019 05:35 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Jon,

Thanks for your reply. That may be what we are looking for.

To be more specific, we need to get the certificate issuer DN and serial number from the authent data, formerly known as XAUTHN_CERT_ISSUER_DN and XAUTHN_CERT_SERIAL_NUMBER. Then we need to forward these attributes to the backend.

If I understand correctly, these attributes are now avaible as x509.issuer_dn and x509.serial_number on the User Mapping module.

How can I know what attributes are available for forwarding using the HTTP-Tag-Value header ?

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 05:10 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Laurent,

If the end goal is to get some attributes from the credential into HTTP headers to backend, then this should be possible without using a custom library.

When the "Tag Value" functionality was first introduced to WebSEAL, it was only possible to work with credential attributes that started tagvalue_ because this was always pre-pended to whatever attribute name was given in the HTTP-Tag-Value extended attribute of the junction object. Perhaps that's why you originally used the custom library to copy these XAUTHN attributes to something that had tagvalue_ on the front?

More recently (including in v7) it is possible to turn off the requirement for attributes to start with tagvalue_. This is done by updating this parameter in WebSEAL configuration file:

force-tag-value-prefix = no

With this set, any attribute from the credential can be sent to backend server in HTTP Header. For example, to send AZN_CRED_AUTHZN_ID in HTTP Header UserDN you would set this extended attribute on junction object:

Name: HTTP-Tag-Value
Value: AZN_CRED_AUTHZN_ID=UserDN

Do you think this would solve your issue or did I misunderstand what you need to achieve?

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed July 24, 2019 11:26 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi,

We are currently running IBM Security Access Manager for Web 7.0.0 with a custom C library that forwards extended attributes to our backend server. The configuration is done via the stanza "[authentication-mechanisms] cred-ext-attrs" that references the library :
cred-ext-attrs = /var/pdweb/wrp1/lib/libxauthn.so

That library searches for "XAUTHN_*" attributes inside the "xnvlist_t *authnInfo" object. Then it copies some of these attributes inside the "xauthn_identity_t *ident" object on "tagValue_*" attributes that are forwarded to the backend server.

The C API is not supported anymore with ISAM 9.0.X. So how can we reproduce the behavior we had with ISAM 7 when running ISAM 9 ?

I have found no documentation about the replacement of the C API for extended attributes forwarding and nothing neither about the certificate authentication identifiers "XAUTHN_*" on ISAM 9 documentation.

------------------------------
Laurent Carrasco
------------------------------

6. RE: [ISAM 9 docker] Extended attributes forwarding to backend servers

Like

Jon Harry

Posted Thu July 25, 2019 08:59 AM

Hi Laurent,

The HTTP-Tag-Value capability can forward any attribute from the user's credential into an HTTP header. So, the attributes available for fowarding via HTTP-Tag-Value is whatever you can get into the credential at authentication time.

[I was assuming that the way you got the headers to the backend in your current implementation was still using HTTP-Tag-Value capability - just using the cred_attr library to get the attributes into the credential. If you're currently doing it some other way I'd be interested to understand that]

There are really three main ways to process an incoming certificate:
   - User Certificate Mapping (only allows override of username - no credential attributes can be set)
   - User Name Mapping (this is what Rob described above and is probably the simplest solution)
   - Certificate EAI (WebSEAL sends certificate details to external HTTP service which returns username+attributes)

Using a Certificate EAI gives the most capability but it means you need to write and host that HTTP Service. Shane Weeden wrote a blog post about running this HTTP Service within AAC Authentication Policy and using it to implement on-demand certificate-->user linking.   You may not need all this function but the concept would also give you what you need to get attributes into the credential.
https://www.ibm.com/blogs/sweeden/linking-client-certificates-isam-account/

I hope one of these options is suitable for you.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM
------------------------------

Original Message

Original Message:
Sent: Thu July 25, 2019 08:37 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Robert,

Your example is fine if you want to use User Mapping module, and I'm not sure I want to use it. If I understand correctly, the attributes added via User Mapping module are added to the iv-creds blob. If that's not the case, then where can we find the added attributes on the backend ?

And the problem with iv-creds is that we have not managed to use the new authorization API without policy and authorization servers. If anyone got this new API working, I am interested.

And that is why I am looking for another way to forward attributes to the backend. HTTP-Tag-Value looks fine, but I don't know what attributes are available for forwarding.

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 07:13 AM
From: Robert Trotter
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The attributes you can use in the attribute mapping module are listed here (issuer_db and serial_number are both listed)
https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/reference/ref_user_mapping_vld_cert_attr.html

This really tripped me up at first -- if you don't specify an attribute in the XSL - then it wont be populated into the trace. There's a tiny line in the doco stating that.

Here's a really simple example I did a couple of years ago. You can see me taking an attribute and then adding it as a tagvalue_* attribute: https://www.robtrotter.com/tech/isam/isam-authenticated-user-mapping

------------------------------
Robert Trotter

Original Message:
Sent: Thu July 25, 2019 05:35 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Jon,

Thanks for your reply. That may be what we are looking for.

To be more specific, we need to get the certificate issuer DN and serial number from the authent data, formerly known as XAUTHN_CERT_ISSUER_DN and XAUTHN_CERT_SERIAL_NUMBER. Then we need to forward these attributes to the backend.

If I understand correctly, these attributes are now avaible as x509.issuer_dn and x509.serial_number on the User Mapping module.

How can I know what attributes are available for forwarding using the HTTP-Tag-Value header ?

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 05:10 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Laurent,

If the end goal is to get some attributes from the credential into HTTP headers to backend, then this should be possible without using a custom library.

When the "Tag Value" functionality was first introduced to WebSEAL, it was only possible to work with credential attributes that started tagvalue_ because this was always pre-pended to whatever attribute name was given in the HTTP-Tag-Value extended attribute of the junction object. Perhaps that's why you originally used the custom library to copy these XAUTHN attributes to something that had tagvalue_ on the front?

More recently (including in v7) it is possible to turn off the requirement for attributes to start with tagvalue_. This is done by updating this parameter in WebSEAL configuration file:

force-tag-value-prefix = no

With this set, any attribute from the credential can be sent to backend server in HTTP Header. For example, to send AZN_CRED_AUTHZN_ID in HTTP Header UserDN you would set this extended attribute on junction object:

Name: HTTP-Tag-Value
Value: AZN_CRED_AUTHZN_ID=UserDN

Do you think this would solve your issue or did I misunderstand what you need to achieve?

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed July 24, 2019 11:26 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi,

We are currently running IBM Security Access Manager for Web 7.0.0 with a custom C library that forwards extended attributes to our backend server. The configuration is done via the stanza "[authentication-mechanisms] cred-ext-attrs" that references the library :
cred-ext-attrs = /var/pdweb/wrp1/lib/libxauthn.so

That library searches for "XAUTHN_*" attributes inside the "xnvlist_t *authnInfo" object. Then it copies some of these attributes inside the "xauthn_identity_t *ident" object on "tagValue_*" attributes that are forwarded to the backend server.

The C API is not supported anymore with ISAM 9.0.X. So how can we reproduce the behavior we had with ISAM 7 when running ISAM 9 ?

I have found no documentation about the replacement of the C API for extended attributes forwarding and nothing neither about the certificate authentication identifiers "XAUTHN_*" on ISAM 9 documentation.

------------------------------
Laurent Carrasco
------------------------------

7. RE: [ISAM 9 docker] Extended attributes forwarding to backend servers

Like

Laurent Carrasco

Posted Fri July 26, 2019 03:22 AM

Hello,

On our ISAM 7, I have seen no specific for forwarding the tagValue attributes to the backend, so I suppose that the custom library is doing this job by adding the attributes to the xauthn_identity_t object. And I believe those attributes are added to the iv-creds blob.

I am currently fighting, yes fighting is the right word, with ISAM to try to add the certificate issuer DN and and serial number to the credentials, but for some reason, I can't authenticate correctly with a certificate, so that the authentication falls back to user/password and I have no certificate data.

Once I manage to add these attributes to the credentials, I think the HTTP-Tag-Value will be the way to go for forwarding these attributes.

------------------------------
Laurent Carrasco
------------------------------

Original Message

Original Message:
Sent: Thu July 25, 2019 08:59 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The HTTP-Tag-Value capability can forward any attribute from the user's credential into an HTTP header. So, the attributes available for fowarding via HTTP-Tag-Value is whatever you can get into the credential at authentication time.

[I was assuming that the way you got the headers to the backend in your current implementation was still using HTTP-Tag-Value capability - just using the cred_attr library to get the attributes into the credential. If you're currently doing it some other way I'd be interested to understand that]

There are really three main ways to process an incoming certificate:
   - User Certificate Mapping (only allows override of username - no credential attributes can be set)
   - User Name Mapping (this is what Rob described above and is probably the simplest solution)
   - Certificate EAI (WebSEAL sends certificate details to external HTTP service which returns username+attributes)

Using a Certificate EAI gives the most capability but it means you need to write and host that HTTP Service. Shane Weeden wrote a blog post about running this HTTP Service within AAC Authentication Policy and using it to implement on-demand certificate-->user linking.   You may not need all this function but the concept would also give you what you need to get attributes into the credential.
https://www.ibm.com/blogs/sweeden/linking-client-certificates-isam-account/

I hope one of these options is suitable for you.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Thu July 25, 2019 08:37 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Robert,

Your example is fine if you want to use User Mapping module, and I'm not sure I want to use it. If I understand correctly, the attributes added via User Mapping module are added to the iv-creds blob. If that's not the case, then where can we find the added attributes on the backend ?

And the problem with iv-creds is that we have not managed to use the new authorization API without policy and authorization servers. If anyone got this new API working, I am interested.

And that is why I am looking for another way to forward attributes to the backend. HTTP-Tag-Value looks fine, but I don't know what attributes are available for forwarding.

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 07:13 AM
From: Robert Trotter
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The attributes you can use in the attribute mapping module are listed here (issuer_db and serial_number are both listed)
https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/reference/ref_user_mapping_vld_cert_attr.html

This really tripped me up at first -- if you don't specify an attribute in the XSL - then it wont be populated into the trace. There's a tiny line in the doco stating that.

Here's a really simple example I did a couple of years ago. You can see me taking an attribute and then adding it as a tagvalue_* attribute:  https://www.robtrotter.com/tech/isam/isam-authenticated-user-mapping

------------------------------
Robert Trotter

Original Message:
Sent: Thu July 25, 2019 05:35 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Jon,

Thanks for your reply. That may be what we are looking for.

To be more specific, we need to get the certificate issuer DN and serial number from the authent data, formerly known as XAUTHN_CERT_ISSUER_DN and XAUTHN_CERT_SERIAL_NUMBER. Then we need to forward these attributes to the backend.

If I understand correctly, these attributes are now avaible as x509.issuer_dn and x509.serial_number on the User Mapping module.

How can I know what attributes are available for forwarding using the HTTP-Tag-Value header ?

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 05:10 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Laurent,

If the end goal is to get some attributes from the credential into HTTP headers to backend, then this should be possible without using a custom library.

When the "Tag Value" functionality was first introduced to WebSEAL, it was only possible to work with credential attributes that started tagvalue_ because this was always pre-pended to whatever attribute name was given in the HTTP-Tag-Value extended attribute of the junction object. Perhaps that's why you originally used the custom library to copy these XAUTHN attributes to something that had tagvalue_ on the front?

More recently (including in v7) it is possible to turn off the requirement for attributes to start with tagvalue_. This is done by updating this parameter in WebSEAL configuration file:

force-tag-value-prefix = no

With this set, any attribute from the credential can be sent to backend server in HTTP Header. For example, to send AZN_CRED_AUTHZN_ID in HTTP Header UserDN you would set this extended attribute on junction object:

Name: HTTP-Tag-Value
Value: AZN_CRED_AUTHZN_ID=UserDN

Do you think this would solve your issue or did I misunderstand what you need to achieve?

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed July 24, 2019 11:26 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi,

We are currently running IBM Security Access Manager for Web 7.0.0 with a custom C library that forwards extended attributes to our backend server. The configuration is done via the stanza "[authentication-mechanisms] cred-ext-attrs" that references the library :
cred-ext-attrs = /var/pdweb/wrp1/lib/libxauthn.so

That library searches for "XAUTHN_*" attributes inside the "xnvlist_t *authnInfo" object. Then it copies some of these attributes inside the "xauthn_identity_t *ident" object on "tagValue_*" attributes that are forwarded to the backend server.

The C API is not supported anymore with ISAM 9.0.X. So how can we reproduce the behavior we had with ISAM 7 when running ISAM 9 ?

I have found no documentation about the replacement of the C API for extended attributes forwarding and nothing neither about the certificate authentication identifiers "XAUTHN_*" on ISAM 9 documentation.

------------------------------
Laurent Carrasco
------------------------------

8. RE: [ISAM 9 docker] Extended attributes forwarding to backend servers

Like

Laurent Carrasco

Posted Fri July 26, 2019 08:07 AM

I have to say I'm a bit lost.

I need to use the Certificate Mapping module to authenticate the user based on his certificate data. The resulting identity is like this :
!userreg base='cn=users,ou=wrp1,o=org' attr='CN'!(SN=<xsl:value-of select="substring-after(substring-before(stsuuser:Attribute[@name='SubjectDN']/stsuuser:Value,','),$mappingAttribute)"/>)!

If I don't use the Certificate Mapping, webseal cannot authenticate the user :
2019-07-26-11:10:45.670+00:00I----- 0x13212072 webseald ERROR ias general azn_authn.cpp 345 0x7fdaf91a1700
-- HPDIA0114E Could not acquire a client credential.

And if I understand correctly, the User Name mapping, also called Authenticated User Mapping can only perform operations on a authenticated user. Am I right on this ?

But then, when I manage to authenticate the user with my certificate mapping rules, the user name mapping module is not called.

Can we use both certificate mapping and user name mapping ?

------------------------------
Laurent Carrasco
------------------------------

Original Message

Original Message:
Sent: Fri July 26, 2019 03:22 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hello,

On our ISAM 7, I have seen no specific for forwarding the tagValue attributes to the backend, so I suppose that the custom library is doing this job by adding the attributes to the xauthn_identity_t object. And I believe those attributes are added to the iv-creds blob.

I am currently fighting, yes fighting is the right word, with ISAM to try to add the certificate issuer DN and and serial number to the credentials, but for some reason, I can't authenticate correctly with a certificate, so that the authentication falls back to user/password and I have no certificate data.

Once I manage to add these attributes to the credentials, I think the HTTP-Tag-Value will be the way to go for forwarding these attributes.

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 08:59 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The HTTP-Tag-Value capability can forward any attribute from the user's credential into an HTTP header. So, the attributes available for fowarding via HTTP-Tag-Value is whatever you can get into the credential at authentication time.

[I was assuming that the way you got the headers to the backend in your current implementation was still using HTTP-Tag-Value capability - just using the cred_attr library to get the attributes into the credential. If you're currently doing it some other way I'd be interested to understand that]

There are really three main ways to process an incoming certificate:
   - User Certificate Mapping (only allows override of username - no credential attributes can be set)
   - User Name Mapping (this is what Rob described above and is probably the simplest solution)
   - Certificate EAI (WebSEAL sends certificate details to external HTTP service which returns username+attributes)

Using a Certificate EAI gives the most capability but it means you need to write and host that HTTP Service. Shane Weeden wrote a blog post about running this HTTP Service within AAC Authentication Policy and using it to implement on-demand certificate-->user linking.   You may not need all this function but the concept would also give you what you need to get attributes into the credential.
https://www.ibm.com/blogs/sweeden/linking-client-certificates-isam-account/

I hope one of these options is suitable for you.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Thu July 25, 2019 08:37 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Robert,

Your example is fine if you want to use User Mapping module, and I'm not sure I want to use it. If I understand correctly, the attributes added via User Mapping module are added to the iv-creds blob. If that's not the case, then where can we find the added attributes on the backend ?

And the problem with iv-creds is that we have not managed to use the new authorization API without policy and authorization servers. If anyone got this new API working, I am interested.

And that is why I am looking for another way to forward attributes to the backend. HTTP-Tag-Value looks fine, but I don't know what attributes are available for forwarding.

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 07:13 AM
From: Robert Trotter
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The attributes you can use in the attribute mapping module are listed here (issuer_db and serial_number are both listed)
https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/reference/ref_user_mapping_vld_cert_attr.html

This really tripped me up at first -- if you don't specify an attribute in the XSL - then it wont be populated into the trace. There's a tiny line in the doco stating that.

Here's a really simple example I did a couple of years ago. You can see me taking an attribute and then adding it as a tagvalue_* attribute:  https://www.robtrotter.com/tech/isam/isam-authenticated-user-mapping

------------------------------
Robert Trotter

Original Message:
Sent: Thu July 25, 2019 05:35 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Jon,

Thanks for your reply. That may be what we are looking for.

To be more specific, we need to get the certificate issuer DN and serial number from the authent data, formerly known as XAUTHN_CERT_ISSUER_DN and XAUTHN_CERT_SERIAL_NUMBER. Then we need to forward these attributes to the backend.

If I understand correctly, these attributes are now avaible as x509.issuer_dn and x509.serial_number on the User Mapping module.

How can I know what attributes are available for forwarding using the HTTP-Tag-Value header ?

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 05:10 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Laurent,

If the end goal is to get some attributes from the credential into HTTP headers to backend, then this should be possible without using a custom library.

When the "Tag Value" functionality was first introduced to WebSEAL, it was only possible to work with credential attributes that started tagvalue_ because this was always pre-pended to whatever attribute name was given in the HTTP-Tag-Value extended attribute of the junction object. Perhaps that's why you originally used the custom library to copy these XAUTHN attributes to something that had tagvalue_ on the front?

More recently (including in v7) it is possible to turn off the requirement for attributes to start with tagvalue_. This is done by updating this parameter in WebSEAL configuration file:

force-tag-value-prefix = no

With this set, any attribute from the credential can be sent to backend server in HTTP Header. For example, to send AZN_CRED_AUTHZN_ID in HTTP Header UserDN you would set this extended attribute on junction object:

Name: HTTP-Tag-Value
Value: AZN_CRED_AUTHZN_ID=UserDN

Do you think this would solve your issue or did I misunderstand what you need to achieve?

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed July 24, 2019 11:26 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi,

We are currently running IBM Security Access Manager for Web 7.0.0 with a custom C library that forwards extended attributes to our backend server. The configuration is done via the stanza "[authentication-mechanisms] cred-ext-attrs" that references the library :
cred-ext-attrs = /var/pdweb/wrp1/lib/libxauthn.so

That library searches for "XAUTHN_*" attributes inside the "xnvlist_t *authnInfo" object. Then it copies some of these attributes inside the "xauthn_identity_t *ident" object on "tagValue_*" attributes that are forwarded to the backend server.

The C API is not supported anymore with ISAM 9.0.X. So how can we reproduce the behavior we had with ISAM 7 when running ISAM 9 ?

I have found no documentation about the replacement of the C API for extended attributes forwarding and nothing neither about the certificate authentication identifiers "XAUTHN_*" on ISAM 9 documentation.

------------------------------
Laurent Carrasco
------------------------------

9. RE: [ISAM 9 docker] Extended attributes forwarding to backend servers

Like

Robert Trotter

Posted Fri July 26, 2019 09:05 AM

The Authenticated User Mapping should be able to cater for that fine. That error message sounds like your user mapping XSL either isn't returning an identity or that it doesn't match the username format. There should be a trace you can enable to check.

------------------------------
Robert Trotter
------------------------------

Original Message

Original Message:
Sent: Fri July 26, 2019 08:07 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

I have to say I'm a bit lost.

I need to use the Certificate Mapping module to authenticate the user based on his certificate data. The resulting identity is like this :
!userreg base='cn=users,ou=wrp1,o=org' attr='CN'!(SN=<xsl:value-of select="substring-after(substring-before(stsuuser:Attribute[@name='SubjectDN']/stsuuser:Value,','),$mappingAttribute)"/>)!

If I don't use the Certificate Mapping, webseal cannot authenticate the user :
2019-07-26-11:10:45.670+00:00I----- 0x13212072 webseald ERROR ias general azn_authn.cpp 345 0x7fdaf91a1700
-- HPDIA0114E Could not acquire a client credential.

And if I understand correctly, the User Name mapping, also called Authenticated User Mapping can only perform operations on a authenticated user. Am I right on this ?

But then, when I manage to authenticate the user with my certificate mapping rules, the user name mapping module is not called.

Can we use both certificate mapping and user name mapping ?

------------------------------
Laurent Carrasco

Original Message:
Sent: Fri July 26, 2019 03:22 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hello,

On our ISAM 7, I have seen no specific for forwarding the tagValue attributes to the backend, so I suppose that the custom library is doing this job by adding the attributes to the xauthn_identity_t object. And I believe those attributes are added to the iv-creds blob.

I am currently fighting, yes fighting is the right word, with ISAM to try to add the certificate issuer DN and and serial number to the credentials, but for some reason, I can't authenticate correctly with a certificate, so that the authentication falls back to user/password and I have no certificate data.

Once I manage to add these attributes to the credentials, I think the HTTP-Tag-Value will be the way to go for forwarding these attributes.

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 08:59 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The HTTP-Tag-Value capability can forward any attribute from the user's credential into an HTTP header. So, the attributes available for fowarding via HTTP-Tag-Value is whatever you can get into the credential at authentication time.

[I was assuming that the way you got the headers to the backend in your current implementation was still using HTTP-Tag-Value capability - just using the cred_attr library to get the attributes into the credential. If you're currently doing it some other way I'd be interested to understand that]

There are really three main ways to process an incoming certificate:
   - User Certificate Mapping (only allows override of username - no credential attributes can be set)
   - User Name Mapping (this is what Rob described above and is probably the simplest solution)
   - Certificate EAI (WebSEAL sends certificate details to external HTTP service which returns username+attributes)

Using a Certificate EAI gives the most capability but it means you need to write and host that HTTP Service. Shane Weeden wrote a blog post about running this HTTP Service within AAC Authentication Policy and using it to implement on-demand certificate-->user linking.   You may not need all this function but the concept would also give you what you need to get attributes into the credential.
https://www.ibm.com/blogs/sweeden/linking-client-certificates-isam-account/

I hope one of these options is suitable for you.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Thu July 25, 2019 08:37 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Robert,

Your example is fine if you want to use User Mapping module, and I'm not sure I want to use it. If I understand correctly, the attributes added via User Mapping module are added to the iv-creds blob. If that's not the case, then where can we find the added attributes on the backend ?

And the problem with iv-creds is that we have not managed to use the new authorization API without policy and authorization servers. If anyone got this new API working, I am interested.

And that is why I am looking for another way to forward attributes to the backend. HTTP-Tag-Value looks fine, but I don't know what attributes are available for forwarding.

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 07:13 AM
From: Robert Trotter
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The attributes you can use in the attribute mapping module are listed here (issuer_db and serial_number are both listed)
https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/reference/ref_user_mapping_vld_cert_attr.html

This really tripped me up at first -- if you don't specify an attribute in the XSL - then it wont be populated into the trace. There's a tiny line in the doco stating that.

Here's a really simple example I did a couple of years ago. You can see me taking an attribute and then adding it as a tagvalue_* attribute:  https://www.robtrotter.com/tech/isam/isam-authenticated-user-mapping

------------------------------
Robert Trotter

Original Message:
Sent: Thu July 25, 2019 05:35 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Jon,

Thanks for your reply. That may be what we are looking for.

To be more specific, we need to get the certificate issuer DN and serial number from the authent data, formerly known as XAUTHN_CERT_ISSUER_DN and XAUTHN_CERT_SERIAL_NUMBER. Then we need to forward these attributes to the backend.

If I understand correctly, these attributes are now avaible as x509.issuer_dn and x509.serial_number on the User Mapping module.

How can I know what attributes are available for forwarding using the HTTP-Tag-Value header ?

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 05:10 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Laurent,

If the end goal is to get some attributes from the credential into HTTP headers to backend, then this should be possible without using a custom library.

When the "Tag Value" functionality was first introduced to WebSEAL, it was only possible to work with credential attributes that started tagvalue_ because this was always pre-pended to whatever attribute name was given in the HTTP-Tag-Value extended attribute of the junction object. Perhaps that's why you originally used the custom library to copy these XAUTHN attributes to something that had tagvalue_ on the front?

More recently (including in v7) it is possible to turn off the requirement for attributes to start with tagvalue_. This is done by updating this parameter in WebSEAL configuration file:

force-tag-value-prefix = no

With this set, any attribute from the credential can be sent to backend server in HTTP Header. For example, to send AZN_CRED_AUTHZN_ID in HTTP Header UserDN you would set this extended attribute on junction object:

Name: HTTP-Tag-Value
Value: AZN_CRED_AUTHZN_ID=UserDN

Do you think this would solve your issue or did I misunderstand what you need to achieve?

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed July 24, 2019 11:26 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi,

We are currently running IBM Security Access Manager for Web 7.0.0 with a custom C library that forwards extended attributes to our backend server. The configuration is done via the stanza "[authentication-mechanisms] cred-ext-attrs" that references the library :
cred-ext-attrs = /var/pdweb/wrp1/lib/libxauthn.so

That library searches for "XAUTHN_*" attributes inside the "xnvlist_t *authnInfo" object. Then it copies some of these attributes inside the "xauthn_identity_t *ident" object on "tagValue_*" attributes that are forwarded to the backend server.

The C API is not supported anymore with ISAM 9.0.X. So how can we reproduce the behavior we had with ISAM 7 when running ISAM 9 ?

I have found no documentation about the replacement of the C API for extended attributes forwarding and nothing neither about the certificate authentication identifiers "XAUTHN_*" on ISAM 9 documentation.

------------------------------
Laurent Carrasco
------------------------------

10. RE: [ISAM 9 docker] Extended attributes forwarding to backend servers

Like

Laurent Carrasco

Posted Fri July 26, 2019 10:50 AM

Thanks Robert, you were totally right, the Authenticated User Mapping was the way to go. I had an error on my XSL file.
Everything is looking fine now. I am able to authenticate based on my certificate data and add extended attributes on the user credentials, both actions being done via the User Mapping module. And finally forward these attributes to the backend via the HTTP-Tag-Value capability.

Thanks a lot Robert and Jon for your help.

------------------------------
Laurent Carrasco
------------------------------

Original Message

Original Message:
Sent: Fri July 26, 2019 09:04 AM
From: Robert Trotter
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

The Authenticated User Mapping should be able to cater for that fine. That error message sounds like your user mapping XSL either isn't returning an identity or that it doesn't match the username format. There should be a trace you can enable to check.

------------------------------
Robert Trotter

Original Message:
Sent: Fri July 26, 2019 08:07 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

I have to say I'm a bit lost.

I need to use the Certificate Mapping module to authenticate the user based on his certificate data. The resulting identity is like this :
!userreg base='cn=users,ou=wrp1,o=org' attr='CN'!(SN=<xsl:value-of select="substring-after(substring-before(stsuuser:Attribute[@name='SubjectDN']/stsuuser:Value,','),$mappingAttribute)"/>)!

If I don't use the Certificate Mapping, webseal cannot authenticate the user :
2019-07-26-11:10:45.670+00:00I----- 0x13212072 webseald ERROR ias general azn_authn.cpp 345 0x7fdaf91a1700
-- HPDIA0114E Could not acquire a client credential.

And if I understand correctly, the User Name mapping, also called Authenticated User Mapping can only perform operations on a authenticated user. Am I right on this ?

But then, when I manage to authenticate the user with my certificate mapping rules, the user name mapping module is not called.

Can we use both certificate mapping and user name mapping ?

------------------------------
Laurent Carrasco

Original Message:
Sent: Fri July 26, 2019 03:22 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hello,

On our ISAM 7, I have seen no specific for forwarding the tagValue attributes to the backend, so I suppose that the custom library is doing this job by adding the attributes to the xauthn_identity_t object. And I believe those attributes are added to the iv-creds blob.

I am currently fighting, yes fighting is the right word, with ISAM to try to add the certificate issuer DN and and serial number to the credentials, but for some reason, I can't authenticate correctly with a certificate, so that the authentication falls back to user/password and I have no certificate data.

Once I manage to add these attributes to the credentials, I think the HTTP-Tag-Value will be the way to go for forwarding these attributes.

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 08:59 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The HTTP-Tag-Value capability can forward any attribute from the user's credential into an HTTP header. So, the attributes available for fowarding via HTTP-Tag-Value is whatever you can get into the credential at authentication time.

[I was assuming that the way you got the headers to the backend in your current implementation was still using HTTP-Tag-Value capability - just using the cred_attr library to get the attributes into the credential. If you're currently doing it some other way I'd be interested to understand that]

There are really three main ways to process an incoming certificate:
   - User Certificate Mapping (only allows override of username - no credential attributes can be set)
   - User Name Mapping (this is what Rob described above and is probably the simplest solution)
   - Certificate EAI (WebSEAL sends certificate details to external HTTP service which returns username+attributes)

Using a Certificate EAI gives the most capability but it means you need to write and host that HTTP Service. Shane Weeden wrote a blog post about running this HTTP Service within AAC Authentication Policy and using it to implement on-demand certificate-->user linking.   You may not need all this function but the concept would also give you what you need to get attributes into the credential.
https://www.ibm.com/blogs/sweeden/linking-client-certificates-isam-account/

I hope one of these options is suitable for you.

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Thu July 25, 2019 08:37 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Robert,

Your example is fine if you want to use User Mapping module, and I'm not sure I want to use it. If I understand correctly, the attributes added via User Mapping module are added to the iv-creds blob. If that's not the case, then where can we find the added attributes on the backend ?

And the problem with iv-creds is that we have not managed to use the new authorization API without policy and authorization servers. If anyone got this new API working, I am interested.

And that is why I am looking for another way to forward attributes to the backend. HTTP-Tag-Value looks fine, but I don't know what attributes are available for forwarding.

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 07:13 AM
From: Robert Trotter
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Laurent,

The attributes you can use in the attribute mapping module are listed here (issuer_db and serial_number are both listed)
https://www.ibm.com/support/knowledgecenter/SSPREK_9.0.7/com.ibm.isam.doc/wrp_config/reference/ref_user_mapping_vld_cert_attr.html

This really tripped me up at first -- if you don't specify an attribute in the XSL - then it wont be populated into the trace. There's a tiny line in the doco stating that.

Here's a really simple example I did a couple of years ago. You can see me taking an attribute and then adding it as a tagvalue_* attribute:  https://www.robtrotter.com/tech/isam/isam-authenticated-user-mapping

------------------------------
Robert Trotter

Original Message:
Sent: Thu July 25, 2019 05:35 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi Jon,

Thanks for your reply. That may be what we are looking for.

To be more specific, we need to get the certificate issuer DN and serial number from the authent data, formerly known as XAUTHN_CERT_ISSUER_DN and XAUTHN_CERT_SERIAL_NUMBER. Then we need to forward these attributes to the backend.

If I understand correctly, these attributes are now avaible as x509.issuer_dn and x509.serial_number on the User Mapping module.

How can I know what attributes are available for forwarding using the HTTP-Tag-Value header ?

------------------------------
Laurent Carrasco

Original Message:
Sent: Thu July 25, 2019 05:10 AM
From: Jon Harry
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Laurent,

If the end goal is to get some attributes from the credential into HTTP headers to backend, then this should be possible without using a custom library.

When the "Tag Value" functionality was first introduced to WebSEAL, it was only possible to work with credential attributes that started tagvalue_ because this was always pre-pended to whatever attribute name was given in the HTTP-Tag-Value extended attribute of the junction object. Perhaps that's why you originally used the custom library to copy these XAUTHN attributes to something that had tagvalue_ on the front?

More recently (including in v7) it is possible to turn off the requirement for attributes to start with tagvalue_. This is done by updating this parameter in WebSEAL configuration file:

force-tag-value-prefix = no

With this set, any attribute from the credential can be sent to backend server in HTTP Header. For example, to send AZN_CRED_AUTHZN_ID in HTTP Header UserDN you would set this extended attribute on junction object:

Name: HTTP-Tag-Value
Value: AZN_CRED_AUTHZN_ID=UserDN

Do you think this would solve your issue or did I misunderstand what you need to achieve?

Jon.

------------------------------
Jon Harry
Consulting IT Security Specialist
IBM

Original Message:
Sent: Wed July 24, 2019 11:26 AM
From: Laurent Carrasco
Subject: [ISAM 9 docker] Extended attributes forwarding to backend servers

Hi,

We are currently running IBM Security Access Manager for Web 7.0.0 with a custom C library that forwards extended attributes to our backend server. The configuration is done via the stanza "[authentication-mechanisms] cred-ext-attrs" that references the library :
cred-ext-attrs = /var/pdweb/wrp1/lib/libxauthn.so

That library searches for "XAUTHN_*" attributes inside the "xnvlist_t *authnInfo" object. Then it copies some of these attributes inside the "xauthn_identity_t *ident" object on "tagValue_*" attributes that are forwarded to the backend server.

The C API is not supported anymore with ISAM 9.0.X. So how can we reproduce the behavior we had with ISAM 7 when running ISAM 9 ?

I have found no documentation about the replacement of the C API for extended attributes forwarding and nothing neither about the certificate authentication identifiers "XAUTHN_*" on ISAM 9 documentation.

------------------------------
Laurent Carrasco
------------------------------

IBM Verify

IBM Verify