Each RADIUS transaction received from the Aruba controller will include a RADIUS VSA called Aruba-Essid-Name. This will give the Amigopod the context of the SSID that the authenticating user is connected to.
What you can do is create two roles within the RADIUS > User Roles section of the Amigopod UI - for example you might create roles called Aruba1 and Aruba2.
In each of these Roles you can add some simple logic to check on the connected SSID and if it doesn't the SSID associated with the access token authenticating to authenticate, you can send an Access-Reject.
To do this add a RADIUS attribute such as Reply-Message (the name of attribute doesn't really matter as it is just a way of processing the business rule) to the new RADIUS Role and enter the following into conditional expression section of the attribute configuration.
Role: Aruba1
return GetAttr('Aruba-Essid-Name') == 'Aruba1' || AccessReject();
Role: Aruba2
return GetAttr('Aruba-Essid-Name') == 'Aruba2' || AccessReject();
This conditional expression will send an Access-Reject to the Aruba controller in the event that the connected SSID doesn't match the SSID recorded in this attribute. By assigned the access token accounts to the appropriate roles when the token are created you will be able to effectively control which captive portal will be permitted for each group of access tokens.
Obviously feel free to change the Aruba1 and Aruba2 names in these examples to suit your SSID names and deployment specifics.
Hope this helps and if you get stuck the TAC can definitely walk you through any of this.
Cam.