Choosing authenticator based on IP address

[Dicta Artisan]

Hi all

I have question on configuring a complex scenario where I am protecting a series of services with a CAS instance (5.2). I have two sets of users that I want authenticated by CAS: a set I can authenticate via a database (using a query database authenticator) and another set I can authenticate delegating to an external SAML IdP (with a pac4J delegated authenticator). Basically some users we manage ourselves, some other users are managed by a different organisation with their own IdP. The application needs to provide equal access to all users to protected services.

Once I define the two authenticators, the default CAS login page presents the username/password boxes with the SAML IdP as an optional button to click on.

I would like that the login screen behaves the following way: connections from a designated IP address range are not presented the login but redirected to an authentication request to the SAML IdP. And that connections arriving from other addresses are presented the login screen for username and password and not offered the option attempting the SAML IdP.

Is there a parameter I can pass to the login screen to request an automatic redirect to the delegated service under certain conditions? And similay, is there an option to present a login where authentication is performed against the database only? In my webapp I can detect the IP address before presenting the CAS login screen to the users, but I am at loss how to configure or drive CAS to adapt the login behaviour for these two cases.

I suspect I can hack the login page to do this, but this would be rather crude. Is there a better option? Thanks for any suggestion you might have.

[Jérôme LELEU]

Hi,

Controlling the behavior by IP is not out-of-the-box. I think your best option here is to override the DelegatedClientAuthenticationAction.

Thanks.

Best regards,

Jérôme

--
- Website: https://apereo.github.io/cas
- Gitter Chatroom: https://gitter.im/apereo/cas
- List Guidelines: https://goo.gl/1VRrw7
- Contributions: https://goo.gl/mh7qDG
---
You received this message because you are subscribed to the Google Groups "CAS Community" group.
To unsubscribe from this group and stop receiving emails from it, send an email to cas-user+u...@apereo.org.
To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/415c786c-1872-45ef-8011-2c37d78406ee%40apereo.org.

[Dicta Artisan]

Thanks for the reply. I will investigate

Another option that appears possible to me ATM is using a custom Groovy theme script where it appears I can select the theme (and thus login screen behaviour) based on incoming parameters. This might be sufficient for me

In any case, I presume being able to decorate authenticators with some kind of validation/selection policy (as in decide which authenticators to apply) might be a useful addition to the framework - in particular to decide if delegation should be applied. I had a look at making a custom authentication policy but not sure how that would work with a mix of delegated authentication and database authenticator...

Cheers

D