Re: [cas-user] About ticket caching and properties handing in CAS 6.2

[Andy Ng]

Hi Sobhen,

1. Not sure what you mean, maybe this page can help you?
https://apereo.github.io/cas/6.2.x/configuration/Configuration-Server-Management.html

2. I never saw.that error before, sorry won't be able to give any insight.

BTW, since you are asking different questions, you might get better luck 
posting a new post in this group, instead of keep posting in this post.

Cheers.
- Andy


On Saturday, 26 December 2020 at 06:46:00 UTC+8 getra...@gmail.com wrote:

> Thanks a lot Andy. We followed the 3rd option and able to make it work. :)
>
> I do have couple of questions, as we didn't any solution for these. Please 
> provide some lights on these.
>
> 1.  Is there anyway to get the ldap url from Catelina.properite file for 
> an external tomcat server? As the environment specified configuration are 
> available in that property file.
>
> 2. We are getting okhttp jar related error whole deploying the 
> application. Feel like conflict is happening. We are using CAS 6.2.2 and it 
> is not happening in local and dev environment.
>
> Thank you in advance.
>
> On Wed, 23 Dec 2020, 7:40 am Andy Ng,  wrote:
>
>> 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,  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 

Re: [cas-user] About ticket caching and properties handing in CAS 6.2

[Rakesh K M]

Thanks a lot Andy. We followed the 3rd option and able to make it work. :)

I do have couple of questions, as we didn't any solution for these. Please
provide some lights on these.

1.  Is there anyway to get the ldap url from Catelina.properite file for an
external tomcat server? As the environment specified configuration are
available in that property file.

2. We are getting okhttp jar related error whole deploying the application.
Feel like conflict is happening. We are using CAS 6.2.2 and it is not
happening in local and dev environment.

Thank you in advance.

On Wed, 23 Dec 2020, 7:40 am Andy Ng,  wrote:

> 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,  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 

Re: [cas-user] About ticket caching and properties handing in CAS 6.2

[Andy Ng]

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,  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 

Re: [cas-user] About ticket caching and properties handing in CAS 6.2

[Rakesh K M]

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,  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 | CLE 019 | r...@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+unsubscr...@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
> 
> .
>

-- 
- 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/CAA6YNd4kBStVg%3DOdbA91foQeQdmrvuO%3DYJPnqDHaNSvpZe1c1w%40mail.gmail.com.

Re: [cas-user] About ticket caching and properties handing in CAS 6.2

[Ray Bon]

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 | CLE 019 | r...@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+unsubscr...@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.

[cas-user] About ticket caching and properties handing in CAS 6.2

[Rakesh K M]

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

-- 
- 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/CAA6YNd5FV%2BGa_gdJZXHdT0kphUheBBRmny7OhAzYi8tUsmUd-w%40mail.gmail.com.