Hi Sobhen,

Would like to know more about your setup first, see if the below correctly 
describe your setup:

- You setup your properties in: 
https://apereo.github.io/cas/6.1.x/configuration/Configuration-Properties.html#ldap-authentication
- You extend the LdapAutheticationHandler and make your own 
CustomLdapAutneticaiontHandler, using the same *cas.authn.ldap[0]* as your 
source of Authentication
- You just intend to use the CustomLdapAuthentcaionHandler, the 
LdapAuthentcaiontHandler is should be disabled for all service

If the above correctly describe your setup, then here's are some idea for 
fix (Not tested)

*Fix #1, disabled LdapAutheticationHandler (Quick fix):*
- Based 
on: 
https://apereo.github.io/cas/6.2.x/services/Configuring-Service-AuthN-Policy.html
- Setup requiredAuthenticationHandlers for your service, set it to 
only CustomLdapAutneticaiontHandler
- Then, LdapAuthentcaiontHandler would never be called for your service
- This fix would have a problem of, if user going to 
https://cas.server/cas/login directly and login, they still would called to 
LdapAuthenticationHandler and that cannot be blocked from my understanding

*Fix #2, override the LdapAuthenticaitonHandlers beans, and inject your own 
custom authentiaction handler:*
- The LdapAuthentiaciontHandler beans is 
here: 
https://github.com/apereo/cas/blob/v6.2.6/support/cas-server-support-ldap/src/main/java/org/apereo/cas/config/LdapAuthenticationConfiguration.java#L179
- You can, go and override it, then set it to use your own 
CusomterLdapAuthenticaiionHandler at this 
line 
https://github.com/apereo/cas/blob/v6.2.6/support/cas-server-support-ldap/src/main/java/org/apereo/cas/config/LdapAuthenticationConfiguration.java#L210
- That case, the default LadpAuthticationHandler willl not be used

*Fix #3, use your own properties:*
- Instead of using cas.authn.ldap[0], which will setup and make 
LdapAuthentcaiontHander available, you can actually:
- Setup your own properties, like *your-org.authn.ldap[0]*, and setup your 
own properties extending 
this: 
https://github.com/apereo/cas/blob/v6.2.6/api/cas-server-core-api-configuration-model/src/main/java/org/apereo/cas/configuration/model/support/ldap/LdapAuthenticationProperties.java
- In your CustomerLdapAutneticainotHandler, make sure the properties is 
point to your own properties

While all of them should works, if I would to setup something like this I 
would go for Fix #3.

See if this would be helpful to you,

Cheers.
- Andy
On Saturday, 19 December 2020 at 17:04:10 UTC+8 getra...@gmail.com wrote:

> Hi Ray,
>
> Thank you very much. It helps.
> I had the following issue. Not sure, I am following the right way. Can you 
> please provide your guidance?
>
> I written a custom LdapAutheticationHandler in my code base and when the 
> authentication is success, the custom authenticator is working fine. But, 
> if the authentication fails, the default LdapAutheticationHandler is 
> getting executed after my custom handler. If I check the CAS source code, I 
> found that if any exception occurred, then the next handler will be 
> executed. Is there way to get rid of the default LdapAutheticationHandler 
> execution?
>
> With regards,
> Sobhen
>
> On Fri, 18 Dec 2020, 10:36 pm Ray Bon, <rb...@uvic.ca> wrote:
>
>> Rakesh,
>>
>> 1. There are a number of options for caching, 
>> https://apereo.github.io/cas/6.2.x/ticketing/Configuring-Ticketing-Components.html.
>>  
>> Your choice will depend on what you already have (software and human), and 
>> how you configure you cas cluster. I have worked with ehcache and 
>> hazelcast. ehcache is distributed and replicated. replication takes time; 
>> you will have to determine if it is fast enough for your needs. hazelcast 
>> is not replicated (though maybe it can be configured). When a node goes 
>> down, that cache is lost; you will have to determine if that frequency is 
>> too disruptive for your users.
>>
>> 2. 
>> https://apereo.github.io/cas/6.2.x/configuration/Configuration-Properties-Security.html
>>  for 
>> security options. We use the spring cloud server, 
>> https://apereo.github.io/cas/6.2.x/configuration/Configuration-Server-Management.html
>>  which 
>> can have encrypted secrets. I recall that someone on this list posted a way 
>> to have a local secrets store that was outside of tomcat (and/or the 
>> packaged image/container; if you are going that route). I would advise 
>> against putting secrets in tomcat (setenv.sh or some such) as tomcat will 
>> print them into the log on startup.
>>
>> 3. There are options for consent, 
>> https://apereo.github.io/cas/6.2.x/webflow/Webflow-Customization-AUP.html, 
>> and password management, 
>> https://apereo.github.io/cas/6.2.x/password_management/Password-Management.html.
>>  
>> We have a separate user management system, so I have not used the above 
>> systems.
>>
>> Ray
>>
>> On Fri, 2020-12-18 at 08:11 +0530, Rakesh K M wrote:
>>
>> Notice: This message was sent from outside the University of Victoria 
>> email system. Please be cautious with links and sensitive information. 
>>
>> Hi all, 
>>
>> I worked on migration of CAS 3 to 6 version. I have couple questions 
>>
>> 1. We were using JBOSS Cache based ticket caching and I can see those are 
>> depreciated in the latest version. Is there any direct alternative for this 
>> rather than using any kind of database for this? I found ehcache based 
>> caching, does that be a good alternative?
>>
>> 2. We are currently having all the securied properties like LDAP URLs, 
>> passwords etc. in external tomcat containers and we don't want to move into 
>> CAS properties file. Is there any way to use the existing properties from 
>> external tomcat container itself?
>>
>> 3. Does new CAS have any machism to update some information in LDAP?
>>
>> Thank you for the support in advance.
>>
>> With regards,
>> Rakesh
>>
>> -- 
>>
>> Ray Bon
>> Programmer Analyst
>> Development Services, University Systems
>> 2507218831 <(250)%20721-8831> | CLE 019 | rb...@uvic.ca
>>
>> I respectfully acknowledge that my place of work is located within the 
>> ancestral, traditional and unceded territory of the Songhees, Esquimalt and 
>> WSÁNEĆ Nations.
>>
>> -- 
>> - 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/b239421d3247d2e2e2eec0aeda74473f018b56dd.camel%40uvic.ca
>>  
>> <https://groups.google.com/a/apereo.org/d/msgid/cas-user/b239421d3247d2e2e2eec0aeda74473f018b56dd.camel%40uvic.ca?utm_medium=email&utm_source=footer>
>> .
>>
>

-- 
- 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/d391ef5a-c695-4e2b-a92d-749042cda817n%40apereo.org.

Reply via email to