The controller appears to be configured with sticky key caching (SKC).
You can verify if a WLAN is configured for SKC with: show wlan wlan_id
With sticky key caching, the client receives and stores a different PMKID for every AP it associates with. The APs also maintain a database of the PMKID issued to the client.
In SKC, the client stores each Pairwise Master Key ID (PMKID) against a Pairwise Master Key Security Association (PMKSA). When a client finds an AP for which it has the PMKSA, it sends the PMKID in the association request to the AP. If the PMKSA is alive in the AP, the AP provides support for fast roaming. In SKC, full authentication is done on each new AP to which the client associates and the client must keep the PMKSA associated with all APs. For SKC, PMKSA is a per AP cache that the client stores and PMKSA is pre-calculated based on the BSSID of the new AP.
With sticky key caching the end device after completing full 802.1x authentication caches the PMKID for that AP. When it roams to the next AP say AP2 it has to complete re-authentication again. It caches the PMKID for this as well. Now when it roams back to the first AP it gives the PMKID in the re-association request. The controller uses this and realizes that the client is authenticated and just goes ahead with the four way handshake. So the client HAS TO authenticate to each new AP that it goes to.
Now this works fine in a small setup due to a limitation on the controller. The controller can cache upto 8 PMKID'S for each client. So the client can roam to 8 AP's again and again without requiring 802.1x authentication. However if it goes to a ninth AP this will required re-authentication (even if the client has previously roamed to this AP) as the controller will not have the necessary PMKID.
