In case of Guest Wireless Internet Access involving Self-Registration with Sponsor Approval workflow, currently a Sponsor can VIEW and APPROVE ALL self-registered guest requests.
Currently in the default sponsor portal, a sponsor will be able to see & approve all guest registrations whether the guest has come to visitor that particular sponsor or not. There was no configuration to LIMIT a sponsor to view only the guests who has come to meet that particular sponsor.
ISE 2.1 For SAML and ISE built-in users you can filter off the person being visited
ISE 2.2 Adds support for AD
Step 9 Configure sponsor Groups
- Approve and view requests from self-registering guests—Sponsors who are included in this Sponsor Group can either view all pending account requests from self-registering guests (that require approval), or only the requests where the user entered the Sponsor's email address as the person being visited. This feature requires that the portal used by the Self-registering guest has Require self-registered guests to be approved checked, and the Sponsor's email is listed as the person to contact.
- Any pending accounts—A sponsor belonging to this group an approve and review accounts that were created by any sponsor.
- Only pending accounts assigned to this sponsor—A sponsor belonging to this group can only view and approve accounts that they created.
There is no direct workaround. A special workaround can be creating your own Sponsor portal using ISE REST APIs
PLEASE NOTE THAT THE PORTAL CUSTOMIZATION AND CUSTOM PORTALS USING REST APIs ARE NOT SUPPORTED BY TAC. THE REST API ITSELF WILL BE SUPPORTED BY TAC.
There is a Rest API call which will enable a sponsor to see all the guest requests. The same API call allows filters to be crafted on certain fixed parameters provided by the guest during his registration request. This article describes the workaround using this API call. In this article I am giving the minimum necessary steps and REST calls in this article and not the code to create the portal itself. The idea is that the System Integrator can build the sponsor portal himself as needed using the language of his choice. In the backend that will make the REST calls to ISE.
---------------------
So First we will modify the GUEST PORTAL to CAPTURE and PASS the email of the sponsor. The default field that takes the “PersonToVisitEmail” cannot be used as a filter in the rest API. However the default field “Company” can be. So we will copy the data of “PersonToVisitEmail” field in the “Company” field. Also we create a new CUSTOM FIELD called “CompanyName” to capture the Company information, since the default “Company” field is being used for other purpose in this workaround. Now just write a Javascript in the Guest Portal to Hide the default “Company” Field and Copy the “PersonToVisitEmail” field into it when clicking the Register Button.
List of supported filters can be found here - http://www.cisco.com/c/en/us/td/docs/security/ise/2-0/api_ref_guide/api_ref_book/ise_api_ref_guest.html#14546
Here are the steps to implement:
Step 1: Navigate to ISE -> Guest Access -> Settings -> Custom Fields to create the new custom field “CompanyName”
Step 2: Navigate to ISE -> Guest Access -> Configure -> Guest Portals -> Select the Portal Name -> In the Portal Behavior and Flow Settings Tab -> Click on Self-Registration Page Settings select the newly added Custom Field
Step 3: Navigate to ISE -> Guest Access -> Configure -> Guest Portals -> Select the Portal Name -> In the Portal Page Customization Tab -> Click on Self-Registration to add some cosmetic details
Step 4: On the same page, now add the javascript to COPY the information from PersonBeingVisited field to Company field and then HIDE the company field. To do this go to Optional Content 2 box, Click on TOGGLE HTML button, copy the below given javascript and then click on TOGGLE HTML button 2 times. If you have successfully added the script, then it will show up only when TOGGLE HTML is ON. If it is OFF, then the box will show up as empty
<script>
jQuery("input[name='guestUser.fieldValues.ui_company']").parent().hide();
jQuery('#ui_self_reg_submit_button').on('click',function(evt){
//evt.preventDefault();
jQuery("input[name='guestUser.fieldValues.ui_company']").val(jQuery("input[name='guestUser.fieldValues.ui_person_visited']").val());
return true;
});
</script><br _moz_editor_bogus_node="TRUE" />
Click the HTML Toggle button 2 times after putting the above script.
Step 5: Click on SAVE button on the top of the page to save the changes.
------------------------------
The configuration is complete. The changes can be tested directly by connecting to the Real Guest Portal or by clicking on the Portal Test URL as shown below
After all the changes are done, this is how the new Guest Portal and Sponsor workflow would look like:
CUSTOM SPONSOR PORTAL USING REST API calls. SPONSOR CAN SEE AND APPROVE ONLY GUESTS THAT CAME TO MEET HIM
ISE REST API is explained here.
To see the Guests for that sponsor
GET https://ISE-IP-ADDRESS:9060/ers/config/guestuser/?filter=company.eq.{sponsoremailid}
To see details about a guest
GET https://ISE-IP-ADDRESS:9060/ers/config/guestuser/{guest-id}
To see details about a guest
PUT https://ISE-IP-ADDRESS:9060/ers/config/guestuser/approve/{guest-id}
Below screenshots show the building of a filter to see only the guests coming to meet particular sponsor. Note in the screenshot that we are passing the email id of the sponsor in the COMPANY field as explained earlier.
