A Sponsor account, if using an external ID source, must be initialized on ISE prior to managing guest accounts for it. This can pose a challenge if using REST API calls from an SSO-authenticated application. Here is how to tackle it.
Scenario:
- Sponsor features are integrated into a custom web application that is using SSO for sponsor login.
- Sponsor users have an AD/LDAP account, and are member of a group associated to a Sponsor Type on ISE.
- All operations for Guest user management are done through REST API calls - ISE sponsor portal is not exposed directly to users.
- A "super-sponsor" user with ALL_ACCOUNT access is used for all API calls, the actual sponsor name is passed as an argument of the API calls as a way to impersonate the actual sponsor.
Additional info: In ISE versions 2.2 and earlier, Guest API call must be authenticated (HTTP Basic Auth) with the credentials of the sponsor users for whom the call is made. This is a problem when API calls are made from an application that doesn't hold the sponsor user credentials, notably when it relies on SSO for authentication. For this, impersonation of a sponsor user can be made by passing the sponsor username as a parameter of the call - this was added as fix for CSCvd48557.
Problem:
The first time an API call is made for a valid AD/LDAP sponsor account - for instance a CreateGuest call - the ISE will return the following error:
|
{
"ERSResponse" : {
"operation" : "POST-create-guestuser",
"messages" : [ {
"title" : "Creating GuestUser failed due to com.cisco.cpm.guestaccess.apiservices.exception.PortalSystemException: Either SponsorUser has not logged in to Sponsor portal at least once or SponsorUser is invalid",
"type" : "ERROR",
"code" : "CRUD operation exception"
} ],
"link" : {
"rel" : "related",
"href" : "https://<ISE-IP>:9060/ers/config/guestuser/",
"type" : "application/xml"
}
}
}
|
Why?
ISE is creating an internal shadow account for each external sponsor user, that will be used for its own metadata. This shadow account will be subject to purge if not used for a configurable duration - hence it might become necessary to do this shadow account creation more than once.
In the context of sponsor feature integration into a 3rd party application, asking sponsor users to login once to the sponsor portal is not an option.
Solution:
Making one API call directly in the name of the sponsor user will create the shadow account - only possible if the sponsor user credentials are available, for instance asking the user to enter his password the first time.
As the problem may happen more than once (if sponsor account is purged), it is a good idea to program this as a error handling routine when a call returns the error.
Note that this will be made irrelevant once SSO authentication support for API calls is added (enhancement request).
