Ricky's Hodgepodge

One of the things that took me more time to understand when starting to use Wildfly was how caching worked for authentication. Besides the functionality is quite different comparing it to the old JBoss-AS so I think that it is good to summarize my findings here. I know how I am, and I will forget part of the idea if I do not use it again in the next months, and I will have doubts that will make me test it again. So better if I spend some time writing the current entry.

In the pre-wildfly times the web part was based in the jbossweb subsystem, which was mainly Tomcat. In Tomcat (at least in its default functionality, I do not know if you can change that default behavior) when a login happens because of a security-constraint the information is stored in the session. Therefore, once the session is authenticated (no matter the mechanism used to do it -BASIC, FORM, KERBEROS,...-) there are no more login calls. The principal associated with the request is retrieved from the session and no more authentication processes are executed. This behavior has the consequence that the requests that use no session (for example static files that does not create a session) are authenticated in every request until the session is created and used as a cache for the authentication information (take this on mind).

But when Wildfly entered in the game, the web part was renewed with the undertow project and, to my surprise, the previous behavior was completely changed (and with no documentation about it). Now the basic idea is that undertow always, and always means always, performs a verification of the account. For that it uses the interface IdentityManager that is called every time to refresh the account. For example looking into the BasicAuthenticationMechanism, the class that manages the BASIC authentication, this line performs the verification of the header. Does it mean that now Wildfly always logs the user in at every request? Bombarding the LDAP or Database to check the password and obtaining the roles all the time? Well, in theory yes, but in the end there are other caches to avoid this.

I am going to focus the entry in the old security subsystem (although I think that elytron is more or less the same). If the final authentication uses a security-domain there is a JAAS stack of login modules that performs the real authentication of the user (LDAP, files, database or any module that is finally authenticating the user). The security domain has a cache-type property, there is a default value that has a static cache of entries using LIRS strategy (there is also a infinispan type that lets configure more specific cache settings). So, using this cache, although undertow performs the verification in every request, when the process finally enters in the security domain code this cache is in place and no real authentication is performed. But, important to remember, if the cache-type is removed in the security domain configuration, every request is authenticated again and again.

At this point the things seem to be clear, now Wildfly authenticates always the request (if security is needed) but there is a cache that can be configured to avoid flooding the user store. Using a more specific cache like infinispan the application can even realize about changes in the final user store (password changed or new roles associated). But I have been talking about Basic authentication until now, using Basic the username and password are sent by the browser in every request, but... What happens with other mechanisms? For example, when using a Form to login, the username and password are only available when the login page is displayed to the user. What does Wildfly do in those cases?

Looking the code undertow performs another trick for those mechanisms. The FormAuthenticationMechanism registers the account when the login is really executed and it is available from there for the subsequent requests (the last parameter true has the effect to cache the account). Once the account is registered by the form mechanism another CachedAuthenticatedSessionMechanism enters in the game and performs the verification of the previous account. So, in summary, if the application is using a mechanism that (by design) has no access to the account in every request (for example Basic can do that but not Form), the mechanism implementation itself should register the account (as the Form mechanism does) and the cached mechanism is the one in charge of getting the cached account and doing its verification. But, important again, even in Form the account is validated in every request (the previously commented cache in the security domain should be configured to avoid this).

So, in the end, the summary is just the following three points:

1. Wildfly starts the authentication process for every request that should be authenticated (information is not stored in session like in the pre-wildfly versions).

2. Even mechanisms that cannot naturally do that (because the username/password pair is not available in every request, Form for example) starts the login in every request.

3. In order to avoid this constant re-login you need to configure cache in the security domain (default or infinispan type).

As I said, the new elytron has not been considered, I do not have all the details but I think that it is more or less the same. You can check it if you are curious about how the new security subsystem works. In case of a security domain the cache is usually configured to the default type and, therefore, there is usually no problem (but better if we understand what is happening under the hood). Hope it helps to somebody else. I think that it is incredible that this kind of changes are not reflected in any documentation or specification paper.

Regards!

Just a very quick entry today. The previous weekend I wasted a lot of time trying to upgrade my phone to LineageOS 16. In general I followed the upgrading guide for my phone model but when I started the adb sideload it always failed with the error: "Error applying update: 7(ErrorCode:: kInstallDeviceOpenError)". I tried Friday evening with no success, I was searching for information a couple of hours at Saturday and I finally got it working on Sunday. I think summarizing what was needed in the blog would be better, maybe it is useful for someone else.

In general the reason seems to be that tissot (my phone model, Xiaomi Mi A1) needs something special in the TWRP boot loader. Finally I got it working after reading this beautiful issue. The problem is explained by the maintainer himself in this thread. My model, unlike most of the usual A/B devices, has a weird partitioning where most partitions are not slotted (except of boot, system, modem). By default, TWRP does not expect to have any non-slotted partition in the A/B OTA package. That is why the installation fails on all TWRP packages except the one provided by the maintainer. So, if having this model, you need to download that exact TWRP image in order to upgrade the system.

After using the correct TWRP version everything went successfully and I have LineageOS 16 in my phone. The main problem was finding the issue, I needed to google a lot until I found that page which described my exact problem.

Regards!

Another quick entry today, I have been involved in a keycloak problem with windows AD. The issue can be summarized in the idea that the Active Directory, when an entry has a lot of values in one attribute (usually a group entry with a lot of users inside member), not all of them are returned by default. There is a MaxValRange limit that controls when the AD starts to omit values and return the values in ranges. Microsoft documents this feature in this note Searching Using Range Retrieval with some useful examples.

Configuring the limit to its lower value (30) in one of my demo envs the results in my tests were the following:

• Retrieving the members from a group with 31 users activates the limit, and only 0-29 values are returned.

  
  ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* member
  dn: CN=InnerGroup,ou=groups,dc=sample,dc=com
  member;range=0-29: CN=aduser5 aduser5,CN=Users,DC=SAMPLE,DC=COM
  member;range=0-29: CN=aduser4 aduser4,CN=Users,DC=SAMPLE,DC=COM
  ...
  member;range=0-29: CN=Administrator,CN=Users,DC=SAMPLE,DC=COM
  

• The missing entry can be obtained requesting more data from 30 to the end (* means the the last attribute value):

  
  ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=30-*"
  dn: CN=InnerGroup,ou=groups,dc=sample,dc=com
  member;range=30-*: CN=aduser6 aduser6,CN=Users,DC=SAMPLE,DC=COM
  

• You can also request just a specific range of the attribute (for example entries 28-29):

  
  ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=28-29"
  dn: CN=InnerGroup,ou=groups,dc=sample,dc=com
  member;range=28-29: CN=aduser5 aduser5,CN=Users,DC=SAMPLE,DC=COM
  member;range=28-29: CN=aduser4 aduser4,CN=Users,DC=SAMPLE,DC=COM
  

• If the upper limit is greater than the current number of values in the attribute * is returned to mark that the last value was reached:

  
  ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=29-40"
  dn: CN=InnerGroup,ou=groups,dc=sample,dc=com
  member;range=29-*: CN=aduser6 aduser6,CN=Users,DC=SAMPLE,DC=COM
  member;range=29-*: CN=aduser5 aduser5,CN=Users,DC=SAMPLE,DC=COM
  

• What happens if the upper range requested is wrong or less than the start range? Just one element is returned.

  
  ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=29-10"
  dn: CN=InnerGroup,ou=groups,dc=sample,dc=com
  member;range=29-29: CN=aduser5 aduser5,CN=Users,DC=SAMPLE,DC=COM
  

• And if the start position is wrong? An error is returned.

  
  ldapsearch -LLL -h sampleserver.sample.com -D "cn=Admin,cn=Users,dc=sample,dc=com" -w XXXXX -b "CN=InnerGroup,ou=groups,dc=sample,dc=com" -s base objectclass=* "member;range=50-*"
  Operations error (1)
  Additional information: 00002121: SvcErr: DSID-031206B8, problem 5012 (DIR_ERROR), data 8995
  

So the range retrieval is easy to use and understand but my main problem was that I needed to test this feature inside keycloak. The basic tests use the apache directory server embedded inside the same java code to test everything with maven. This range retrieval feature is very AD specific (I do not know any other LDAP directory that performs the same) so the Apache implementation does not do the same by default. But the project lets you implement your own interceptors. And, no sooner said than done, I implemented a ranged interceptor to emulate AD behavior. My implementation is very easy, it only applies to one attribute that should be specified, but range attribute value retrieval can be emulated in an embedded LDAP server for it, so I can write some tests to check if the implementation is working smoothly.

The entry's goal is just saving my interceptor here. It is just one class and some easy junit tests that check everything is working, but better if the class is saved here. The maven project can be downloaded from here.

Best regards!