Thanks Jack.
With your last yesterday's post, we were able today just before lunch time to connect/authenticate successfully with a remote AD user registry using the Federated Repository approach (ldap.conf). And, we are able to authenticate users using various/different UserLookupHelper helpers' instances (some with LDAP server connection, some with ldap.conf as the seed) at the same time in the same runtime.
We've learned a lot with this use case. The worst thing is that I had implemented Federated Repositories 2 years ago in a PoC but in the context of WebSEAL, not from an ISAM Liberty Runtime standpoints.
The ISAM framework is very flexible, and there are so many ways of implementing things. I think that when I will end my career, there will still be some areas of the platform that I will not have covered (-;
Original Message:
Sent: Thu July 02, 2020 11:15 AM
From: JACK YARBOROUGH
Subject: Using third party classes in AAC
Hello Sylvain,
Since you are not clustered the way you initialize the UserLookupHelper can be unique to each appliance.
Even if you are in the same appliance, it's totally dependent on how you initialize the class. For example, an OAUTH mapping rule could use the ldap.conf and one infomap could utilize the 'Username Password' Authentication method while another one initializes using a set of properties.
When using a Federated Directory and initializing the UserLookupHelper using the ldap.conf and basic user support is enabled it will search for users based on the 'basic-user-principal-attribute' value.
I've attached a file that can perform authentication against a given directory server. It takes advantage of how the UserLookupHelper inherently works and can only provide authentication via the 'bind' method, not the compare method.
It's not recommended to use this method but if you cannot find a solution that is documented it technically works. I'd performance test it.
------------------------------
JACK YARBOROUGH
Original Message:
Sent: Wed July 01, 2020 11:47 PM
From: Sylvain Gilbert
Subject: Using third party classes in AAC
Hi Jack
Our ISAM Liberty appliances are not clustered in any way with other ISAM appliances of the topology, those with primary/secondary roles; nor are they clustered together. Moreover, we have a local policy server on them configured (along with an embedded ldap) just for the sake of being able to run a local webseal proxy in front of Liberty Runtime. I am skipping lots of details here, but this is just to say that when we I go to LMI->Web->Runtime->Runtime Component from our ISAM Liberty appliances, the configured "Runtime" is "local", and is unrelated to our actual ISAM Security Domain components running elsewhere (Policy Server/ITDS) where the real ISAM users resides. I am just bringing that up anyway for the sake of clarity.
As pointed previously out by Sebastien, UserLookupHelper works great in our InfoMap with a LDAP Server connection configured and pointing to our ISAM Security Domain infrastructure. We can search and authenticate our regular ISAM users.
We have control in our custom InfoMap to decide how we will perform search/authentication function for each of our affiliates, as we are performing reverse lookup in the email address (user id), and then branching in the code to the specific business logic. We are performing the usual UserLookupHelpler search/authenticate against "our" ISAM users, but we will perform a slightly different lookup/authenticate method for affiliates that reside in non-ISAM user registries. This is just to say that we have the liberty of working with different classes, objects, and configuration types. We have, for instance, individual LDAP server connections pre-configured for each remote LDAP user registries (ISAM-related or not). We are in fact kind of replicating the ISAM WebSEAL Federated Repositories approach but with more liberty, and with more customization possible for every individual remote LDAP registries. At least, that was our intention.
Now, going back to your point of configuring the Web->Runtime Components from our ISAM Liberty appliances, are you implying that as long as the "primary" ldap configured is an ISAM User Registry (which in our case is empty), it is not an issue if the other LDAP servers defined in the list are not ISAM User Registry, and only contain Basic Users?
If so, yes, we could configure all our affiliates LDAP server in the list (ldap.conf), and the primary LDAP server would be the local embedded LDAP server which is pretty much vanilla and empty. Being defined as the primary, it would receive all LDAP search operations first and would return no results, then the lookup would continue and resume with the next LDAP server in the list. That would not be ideal but would be an ok workaround (until we find a working set of sample for using the v10 NativeLDAPHelper). We have only 3 other remote LDAP registries so I think scalability would not be a huge issue here.
I am looking at this older piece of masterclass configuration documentation (Federated Repositories and Basic Users):
[server:win2008 AD]
host = win2008.demo.com
port = 636
bind-dn = cn=administrator,cn=users,dc=demo,dc=com
ssl-enabled = yes
suffix = dc=demo,dc=com
ignore-if-down = yes
basic-user-principal-attribute = samAccountName
Does this sample means that by properly setting the "basic-user-principal-attribute" value to the "email" attribute that we will be able to lookup users based on their email address instead ?
So just to be clear, we could use the Federated Repository approach from our ISAM Liberty appliances and our InfoMap would still use for our affiliates the UserLookupHelp() but configured and initiative differently ?
Last question but not less important: can there be at any time in the same ISAM Liberty JVM different instances of UserLookupHelp()configured differently, i.e. some helper configured to use a remote ISAM user registry (LDAP server connection), and some other configured to use ldap.conf Federated Repository?
Thanks
------------------------------
Sylvain Gilbert
Original Message:
Sent: Wed July 01, 2020 04:29 PM
From: Sebastien Morissette
Subject: Using third party classes in AAC
Hi Jack,
thanks for confirming : "'UserLookupHelper' is meant to be used in conjunction with an ISAM primary registry server"
We had assumed as much after trial and error.
I have asked Sylvain Gilbert from IFC to comment on our reasons / rationale for not using the "Federated Directories" approach, he will comment shortly.
I am really trying to achieve all of this through serverconnections, This is why the v10 is interesting as it adds the support for native ldap searches through those packages i've pasted above.
We can assume for now that if we were to make those classes work, we would strongly consider updating to v10 as this is very important for us and required for monday the 6th of july.
i've imported the extension jar file into my eclipse and I was able to add my own clases to it and re-import into the Appliance as an extension. However, once it is there, i'm at a loss to how to create an authentication Policy that will use it.. the documentation is slim and also points to an old developperworks link that is no longer available, i've opened a support case for that as well,
Thanks again for any input or thougths you might have to get us operational.
best regards,
Seb
------------------------------
Sébastien Morissette
Architecte TI Spécialiste – Infrastructure, Sécurité et Services TI – Amérique du Nord
IT Architect Specialist – Infrastructure, Security and IT Services – North America
Intact Corporation Financière
Intact Financial Corporation
Original Message:
Sent: Wed July 01, 2020 02:16 PM
From: JACK YARBOROUGH
Subject: Using third party classes in AAC
Hello Sebastien,
First, the 'UserLookupHelper' is meant to be used in conjunction with an ISAM primary registry server, the one that holds the 'secAuthority=Default' directory.
It is not meant to be used for simple Directory searches.
Secondly, if you have the AD and ITDS servers defined as 'Federated Directories' in the 'ldap.conf' of your Runtime Component you can just initialize it as such :
userLookupHelper.init(false);
JavaDoc reference:
public void init(boolean useAuthService, java.util.Properties overrideProperties)
Initialize a UserLookupHelper which will use either the configuration in the ISAM RTE, or the configuration in the Username Password authentication mechanism.
Parameters:
userAuthService - if true then the username password configuration will be used, if false then the call is the same as using
overrideProperties - properties to pass down to rgy. Will be applied after the usual properties are loaded, meaning they will override any configuration which the util attempts to populate. If null will be ignored.
Using 'init(false)' will require that you populate the following stanza with credentials to the registry that holds your 'secAuthority=Default' suffix.
To determine that registry, find the value for the following entry :
ldap.conf:
[ldap]
...
host =
IF the above entry is set to '127.0.0.1' you are using the embedded LDAP to hold the Verify Access (Access Manager) schema and to initialize the userLookupHelper using the ldap.conf you'll need to add the following :
ldap.conf:
...
[bind-credentails]
bind-dn = cn=root,secAuthority=Default
bind-pwd = passw0rd
The value of 'passw0rd' is the default password for the embedded ldap and can (and should) be changed.
IF the host entry is not the localhost then you should update the '[bind-credentials]' stanza with the bind-dn and bind-pwd of the associated registry server.
Using the 'ldap.conf' configuration will allow for you to utilize the Federated Directory and basic user support.
Can you clarify whether you have the TDS/AD servers defined in the ldap.conf or if you're specifically trying to use server connections?
------------------------------
JACK YARBOROUGH
Original Message:
Sent: Wed July 01, 2020 02:01 PM
From: Sebastien Morissette
Subject: Using third party classes in AAC
Hi Jack,
We are implementing an info map login mechanism but we need to perform login based on email address because we are connecting to 4 different backend ldaps for many different affiliâtes of ours.
Unfortunately, only one of them is isam / itds, the other three are active directory and our attempts to use the provided methods both on 9.0.7 or the new 10.0 native ldap helper are unsuccessful.
I've opened a Case with support for version 10 but on our code running version 9, the userlookuphelper class ends up failing because it tries to lookup IBM specific security elements and forces us to specify an attribute management domain.
init(LdapServerConnection connection, java.lang.String searchFilter, java.lang.String mgmtDomain)
Initialize this lookup util with a server connection.
So the traces show it finds the user in AD but fails when those specific IBM security items are looked up.
No attempt to remove , send empty or null values for the management domain have yielded any results as this ends up giving null pointer exception or saying the mgmtDomain does not exist.
So in short, we are expected to deliver an authentication mechanism looking up users in the right user registry / ldap based on matching the Corporate email entered at login prompt. but these ldaps are all remote Active Directory.
So I'm looking for options as I need working code for Monday :)
This is why the option of having or building that extension or helper classe i built in there would be great…
This or getting the native ldap helper classes from version 10 to work.
com.ibm.security.access.ldap
com.ibm.security.access.ldap.utils
https://www.ibm.com/support/pages/node/6213574 provides the javadoc for version 10.
to date my attempts have generated stack traces after import if I try to import the AttributeUtil as a class, or undefined errors if I import the package in the infomap.. Level 3 support is working on the case to figure out what is going on.
thanks !!!
Thanks
Seb
------------------------------
Sébastien Morissette
Architecte TI Spécialiste – Infrastructure, Sécurité et Services TI – Amérique du Nord
IT Architect Specialist – Infrastructure, Security and IT Services – North America
Intact Corporation Financière
Intact Financial Corporation
Original Message:
Sent: Wed July 01, 2020 12:36 PM
From: JACK YARBOROUGH
Subject: Using third party classes in AAC
Hello Sebastien,
Using the '3rd Party Jar files' is only valid in the context of creating a Custom Authentication Mechanism or a Custom Obligation for use in AAC.
A valid extension will extend either the 'com.ibm.security.access.extension.authn.AuthenticationMechanism' interface or the 'com.ibm.security.access.extension.authz.ObligationHandler' interface.
It is not meant as a vector to put third party jars used for mapping on the appliance and to my knowledge the AAC/Federation mapping rules are sandboxed from accessing third party classes uploaded via an extension anyways.
There used to be a Wiki article demonstrating how to create a custom authentication mechanism but it is outdated and does not compile.
As of this moment there are no current examples on how to make a custom authentication mechanism or obligation as most functionality can be achieved via the InfoMap Authentication Mechanism that utilizes our built-in classes.
The following is the documentation we have for developing for AAC:
https://www.ibm.com/support/knowledgecenter/en/SSPREK_9.0.7/com.ibm.isam.doc/develop/concept/con_mobile_sdk.html
Furthermore, you can download the JAR that contains the Authentication Mechanisms and Obligations from the following location on the appliance:
Manage System Settings -> Secure Settings -> File Downloads ->> access_control -> sdk -> com.ibm.security.access.extension_8.0.0.zip
That file includes the 'com.ibm.security.access.extension_8.0.0.jar' which contains the interfaces necessary to develop your own custom authentication mechanism or custom obligation.
Even if your custom authentication mechanism or custom obligation handler utilized 3rd party jars and classes they are not available from the JavaScript mapping rules.
The proper way forward would be to open an Enhancement Request for functionality allowing to upload 3rd party classes via Jars to the appliance for use in the mapping rules:
https://www.ibm.com/developerworks/rfe/?BRAND_ID=301
Regardless, what are you trying to achieve that you cannot do with the current classes available on the appliance?
------------------------------
JACK YARBOROUGH
Original Message:
Sent: Tue June 30, 2020 12:44 PM
From: Sebastien Morissette
Subject: Using third party classes in AAC
Hi, i've stumbled upon this link while looking up options to do external ldap authentication against active directory or other types of ldaps in a mapping rule.
my thought would be to build my own ldap connector class and have it uploaded to the Appliance and then consume the classes Inside my mapping rule.
has anyone allready done this, when I try to upload my "built" jar file from eclipse, the Appliance tells me my file is invalid..
FBTRBA313E The extension bundle file is not valid.
Using Third-Party Classes in an ISAM AAC Custom Authentication Mechanism/Obligationhttps://www.ibm.com/support/pages/using-third-party-classes-isam-aac-custom-authentication-mechanismobligation
------------------------------
Sébastien Morissette
Architecte TI Spécialiste – Infrastructure, Sécurité et Services TI – Amérique du Nord
IT Architect Specialist – Infrastructure, Security and IT Services – North America
Intact Corporation Financière
Intact Financial Corporation
------------------------------