ISE Sponsor Portal - Sponsor Group Other Conditions using URL match?

[Arne Bier]

Hello,

In the ISE Sponsor Groups configuration, in addition to checking ISE/AD Groups, there is also the ability to check for "Other conditions (optional) - sponsor must match all conditions"

I want to create a condition that inspects the URL to see whether it contains the string "oneclicktoken", and if that string is found in the URL, then allow that Sponsor user to login. 

The reason for this check, is to prevent users from logging into the Sponsor Portal, unless they have received an email approval link. When an account approval link is sent to the "person being visited", it contains the special token in the URL, which means the user does not have to login to the Sponsor Portal using their username and password. At least, it's valid for a 3 hour period. This could be a neat way to stop people logging into the Sponsor Portal directly.

I went through all the attributes available but I can't find one that exposes the URL that was used to access the Sponsor Portal.

Is there any handy guide that explains how the ISE Dictionary works?  I thought of creating a User Dictionary, but it's not obvious how that works.

regards

Arne

[Vikas K · Accepted solution]

Hello Arne,

URL Inspection is not a function ISE yet. Unfortunately, portal URLs won't be exposed to or inspected via ISE dictionaries.

-------------------------------------------------------------
If you find my reply solved your question or issue, kindly click the 'Accept as Solution' button and vote it as helpful.

You can also learn more about ISE through our live Ask the Experts (ATXs) session. Check out Cisco ATXs Resources [https://community.cisco.com/t5/security-knowledge-base/cisco-endpoint-security-ask-the-experts-resources/ta-p/4394492] to view the latest schedule for upcoming sessions, as well as the useful references, e.g. online guides, FAQs.
-------------------------------------------------------------

[Arne Bier]

Hi @Vikas K - I will make a formal enhancement request to expose some kind of attribute (Boolean or otherwise) to indicate that the Sponsor authentication is part of a regular portal login, or part of a single-click flow. I indicated that as far as I could see, the incoming URL gives a very clear hint about the method being used. The enhancement request would hopefully result in a dictionary attribute that can be combined with the "other conditions" to make this portal experience fit more use cases.

[Vikas K]

Thank you Arne! Sure, its possible to achieve this, but requires changes to be made in the platform. Please let me know if there is anything else you need.

[jack.warmya]

Hi Vikas,

I am also interested using this method to validated the guest request. Is there any configuration guide to follow ? Thanks a lot 

[jack.warmya]

Hi Arne,

Have you got some feedbacks from Cisco for the solution or configuration guide ? I would like to implement the same as you mentioned to check the the string "oneclicktoken", and if that string is found in the URL, then allow that Sponsor user to login. 

The objective is to avoid to check the sponsor email in AD using single click approval solution. For me once the sponsor received the email, which means the sponsor is already an valided user in enterprise domain. It is not necessary to check again in AD again of the sponsor.

In additional, we can use Javascript to limit the "persion being visited" email to enterprise domain to enhance the security.

<script>
 
     setTimeout(function(){
 
          $.validator.addMethod("customemailvalidator", function(value, element) {
 
       return /^(\w+\.?)+@example\.com$/.test( value );
 
     }, 'Please enter a valid email.');
 
     jQuery("[name='guestUser.fieldValues.ui_person_visited']").rules("add",{customemailvalidator:true});
 
     }, 50);
 
</script>

[Arne Bier]

Hi @jack.warmya 

I didn't get a bug ID or such to track the progress of my "wish".  I decided in the end that it would be a long battle to get Cisco to agree to put such a feature into ISE. And the lack of such a feature was not a showstopper for my customer.

But if others feel strongly about it then they should raise a feature request via Make A Wish . I have had replies from the BU in the past.