Re: [cas-user] ervice registration only allows set of IP addresses?
Baron, https://apereo.github.io/cas/6.6.x/services/Service-Access-Strategy-Http.html Ray On Wed, 2022-11-23 at 15:57 -1000, Baron Fujimoto wrote: Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information. I'm afraid my search-fu is failing me with the way the docs are organized now. I'm looking for a way to for a CAS service registration to only allow certain IP addresses (hopefully defined using some reasonable regex or network notation, e.g. CIDR, etc) Can anyone point me to the right reference(s)? -- Baron Fujimoto mailto:ba...@hawaii.edu>> ::: UH Information Technology Services minutas cantorum, minutas balorum, minutas carboratum descendus pantorum -- - 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+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/49eb6902d26636163e40227ad6aecb96513690c0.camel%40uvic.ca.
[cas-user] Authentication Policies Configuration (Handlers chaining)
Hello everyone, If this is not the right place to post this, sorry and please point me to the right forum/discussion channel. I’m a software engineer (at neomia) and we developed an MFA plugin (Pulse) to add a second authentication factor to CAS based on typing biometrics. We developed a specific *AuthenticationHandler (PulseAuthenticationHandler)* that currently works correctly but we need some help to configure the authentication policy. In a configuration where we have two handlers (LdapAuthenticationHandler and PulseAuthenticationHandler) we would like to have this behavior: - Specify a desired execution order (e.g. LdapAuthenticationHandler is always executed first, PulseAuthenticationHandler second); - If one handler fails, the following handlers in the authentication chain must not be invoked and the authentication must be refused (e.g. if LdapAuthenticationHandler fails – as first factor, the PulseAuthenticationHandler – as second factor - must not be invoked and the authentication must be refused); - The authentication is successful if and only if all the specified authentication handlers are invoked and their results are successful. In all possible configurations that we tried (with the different possible values - https://apereo.github.io/cas/6.6.x/authentication/Configuring-Authentication-Policy.html). The PulseAuthenticationHandler still gets invoked and we couldn’t figure out how to stop the authentication chain right after the first handler failure. We would be grateful if someone could point us in the right direction. Thanks Guillaume Laroyenne neomia -- - 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+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/297755af-92f0-4535-9a91-2607910c6647n%40apereo.org.
Re: [cas-user] Authentication Policies Configuration (Handlers chaining)
Guillaume, Perhaps, https://apereo.github.io/cas/6.6.x/authentication/Configuring-Authentication-Policy-All.html more generally, https://apereo.github.io/cas/6.6.x/authentication/Configuring-Authentication-Components.html#authentication-sequence This blog may also provide some hints, https://fawnoos.com/2020/10/21/cas62-authn-handlers/ Ray On Thu, 2022-11-24 at 03:15 -0800, Neomia Dev wrote: Notice: This message was sent from outside the University of Victoria email system. Please be cautious with links and sensitive information. Hello everyone, If this is not the right place to post this, sorry and please point me to the right forum/discussion channel. I’m a software engineer (at neomia) and we developed an MFA plugin (Pulse) to add a second authentication factor to CAS based on typing biometrics. We developed a specific AuthenticationHandler (PulseAuthenticationHandler) that currently works correctly but we need some help to configure the authentication policy. In a configuration where we have two handlers (LdapAuthenticationHandler and PulseAuthenticationHandler) we would like to have this behavior: * Specify a desired execution order (e.g. LdapAuthenticationHandler is always executed first, PulseAuthenticationHandler second); * If one handler fails, the following handlers in the authentication chain must not be invoked and the authentication must be refused (e.g. if LdapAuthenticationHandler fails – as first factor, the PulseAuthenticationHandler – as second factor - must not be invoked and the authentication must be refused); * The authentication is successful if and only if all the specified authentication handlers are invoked and their results are successful. In all possible configurations that we tried (with the different possible values - https://apereo.github.io/cas/6.6.x/authentication/Configuring-Authentication-Policy.html). The PulseAuthenticationHandler still gets invoked and we couldn’t figure out how to stop the authentication chain right after the first handler failure. We would be grateful if someone could point us in the right direction. Thanks Guillaume Laroyenne neomia -- - 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+unsubscr...@apereo.org. To view this discussion on the web visit https://groups.google.com/a/apereo.org/d/msgid/cas-user/6297be8f9220072c6d1ce22e8ef1ba275fcfd14b.camel%40uvic.ca.
Re: [cas-user] Impersonation / Surrogate-Authentication
Thank you both for the help! I was able to get it working, albeit with the
REST version rather than LDAP. The JSON version would probably work as well.
#
# LDAP ATTRIBUTE REPOSITORY
#
cas.person-directory.active-attribute-repository-ids=attributes
cas.person-directory.attribute-resolution-enabled=true
cas.person-directory.principalAttribute=sAMAccountName
cas.person-directory.return-null=false
cas.person-directory.principal-resolution-failure-fatal=true
cas.person-directory.use-existing-principal-id=false
cas.authn.attribute-repository.core.default-attributes-to-release=cn,givenName,sn,displayName,affiliation
cas.authn.attribute-repository.ldap[0].id=attributes
cas.authn.attribute-repository.ldap[0].order=0
cas.authn.attribute-repository.ldap[0].binary-attributes.objectGUID=objectGUID
cas.authn.attribute-repository.ldap[0].attributes.userPrincipalName=userPrincipalName
cas.authn.attribute-repository.ldap[0].attributes.dn=distinguishedName
cas.authn.attribute-repository.ldap[0].attributes.sn=sn
cas.authn.attribute-repository.ldap[0].attributes.cn=cn
cas.authn.attribute-repository.ldap[0].attributes.givenName=givenName
cas.authn.attribute-repository.ldap[0].attributes.sAMAccountName=sAMAccountName
cas.authn.attribute-repository.ldap[0].attributes.displayName=displayName
cas.authn.attribute-repository.ldap[0].attributes.memberOf=memberOf
cas.authn.attribute-repository.ldap[0].connectTimeout=PT3S
cas.authn.attribute-repository.ldap[0].baseDn=[base_dn]
cas.authn.attribute-repository.ldap[0].subtreeSearch=true
cas.authn.attribute-repository.ldap[0].searchFilter=(sAMAccountName={user})
cas.authn.attribute-repository.ldap[0].bindDn=[bind_user]
cas.authn.attribute-repository.ldap[0].bindCredential=[bind_password]
cas.authn.attribute-repository.ldap[0].ldap-url=[ldap_url]
#
# Impersonation / Surrogate Authentication
#
cas.authn.surrogate.rest.url=[url]
cas.authn.surrogate.principal.active-attribute-repository-ids=attributes
cas.authn.surrogate.principal.attribute-resolution-enabled=true
cas.authn.surrogate.principal.principal-attribute=sAMAccountName
cas.authn.surrogate.principal.principal-resolution-failure-fatal=true
On Thursday, November 24, 2022 at 12:36:30 AM UTC-5 jeffrey...@gmail.com
wrote:
> Try this as well.
>
> https://fawnoos.com/2018/05/07/cas-impersonation-authn/
>
> -Jeff
>
> On Wed, Nov 23, 2022 at 8:21 PM Matthew Gordon wrote:
>
>> Thank you Jonathon.
>>
>> On Monday, November 14, 2022 at 10:16:12 PM UTC-5 Jonathon Taylor wrote:
>>
>>> Hi Matt,
>>>
>>> That is the entirety of our surrogate configuration. CAS will return
>>> the surrogate user attributes, not the authenticated user.
>>>
>>> Jonathon
>>>
>>> On Tue, Nov 8, 2022 at 12:37 PM Matthew Gordon wrote:
>>>
Also does it return the surrogate users attributes, or the
authenticated users attributes?
Thank you,
Matt
On Monday, November 7, 2022 at 3:55:38 PM UTC-5 Matthew Gordon wrote:
> Thank you Jonathon. I will have to look at doing it via LDAP. I was
> just trying to do it via a local JSON file. Is that the entirety of your
> surrogate config?
>
> Thank you,
> Matt
>
> On Monday, October 31, 2022 at 12:51:47 PM UTC-4 Jonathon Taylor wrote:
>
>> Not sure if this helps, but we use impersonation with LDAP and we did
>> not have to use a groovy script. We are on 6.5.8. Here's an example of
>> our configuration:
>>
>> cas.authn.surrogate.ldap.ldap-url=ldap://
>> cas.authn.surrogate.ldap.base-dn=.
>> # this filter gets the attributes of the account being impersonated
>> cas.authn.surrogate.ldap.search-filter=(&(objectClass=eduPerson)(|(cn
>> ={0})))
>> cas.authn.surrogate.ldap.bind-dn=
>> cas.authn.surrogate.ldap.bind-credential=
>> cas.authn.surrogate.ldap.use-start-tls=true
>>
>> # this is the format of the group that a person has to be in
>> # in order to impersonate the 'surrogate'
>> cas.custom.properties.surrogate-format=cn=group-{surrogate}
>> # this builds the list of authorized accounts for impersonation
>> cas.authn.surrogate.ldap.surrogate-search-filter=(&(cn={user})(
>> isMemberOf=${cas.custom.properties.surrogate-format}))
>> cas.authn.surrogate.ldap.member-attribute-name=isMemberOf
>> # this extracts the 'friendly' name of the account to be impersonated
>> cas.authn.surrogate.ldap.member-attribute-value-regex=cn
>> =group-([^,]+)
>>
>> On Fri, Oct 28, 2022 at 12:43 PM Matthew Gordon
>> wrote:
>>
>>> I am using only LDAP (AD) as my attribute repository.
>>>
>>>
>>> https://apereo.github.io/cas/6.5.x/authentication/Surrogate-Authentication.html#surrogate-principal-resolution
>>>
>>> I am trying to get it to resolved the impersonated users
