Dear Ray
Thank you for your response and suggestion.
I have considered the option of OIDC at the end of service. However - the service has been deployed in tomcat container. The tomcat container support OIDC only via
https://github.com/boylesoftware/tomcat-oidcauth and the documentation of the above connector states
"This authenticator is intended for traditional Java Servlet
web-applications with server-side page rendering and use of HTTP
sessions. It is not intended for RESTful applications."
So I am really not able to find any connector that supports OIDC for Tomcat. Now this leaves the option for changing the container - but the question is to which container? One option is to consider the sample webapp that is available in CAS to test the OIDC via MITREid Connect.
So not really sure - if the above would be better than proxy ticket authentication -that is specifically meant for RESTful services.
I guess- I am making a small error somewhere. If you see the logs below - the proxy ticket is generated and validated successfully. However on the server side - the function used for validation of Proxy ticket is "Cas20WithoutProxyingValidationSpecification". Now sure what parameters or URL has to be passed to ensure proxy validation.
########################################################################################
2022-07-11 17:06:30,096 DEBUG [org.apereo.cas.ticket.registry.AbstractMapBasedTicketRegistry] - <Added ticket [PT-6-e6suh9pQVu2HclSmOocZARhbEO0-cas] to registry.>
2022-07-11 17:06:30,096 INFO [org.apereo.inspektr.audit.support.Slf4jLoggingAuditTrailManager] - <Audit trail record BEGIN
=============================================================
WHO: rit...@XXXX.com
WHAT: PT-6-e6suh9pQVu2HclSmOocZARhbEO0-cas for
https://casclient1.mytbits.com/basic-ritesh/?renew=trueACTION: SERVICE_TICKET_VALIDATE_SUCCESS
APPLICATION: CAS
WHEN: Mon Jul 11 17:06:30 CEST 2022
CLIENT IP ADDRESS: 127.0.0.1
SERVER IP ADDRESS: 127.0.1.1
=============================================================
>
2022-07-11 17:06:30,097 WARN [org.apereo.cas.validation.AbstractCasProtocolValidationSpecification] - <[
Cas20WithoutProxyingValidationSpecification]
is not internally satisfied by the produced assertion>2022-07-11 17:06:30,097 WARN [org.apereo.cas.web.AbstractServiceValidateController] - <
Service ticket [PT-6-e6suh9pQVu2HclSmOocZARhbEO0-cas] does not satisfy validation specification.>
########################################################################################
In the above case- I am calling the URL -
https://casclient1.mytbits.com/basic-ritesh/?renew=true&ticket=PT-6-e6suh9pQVu2HclSmOocZARhbEO0-cas , the casclient filter is correctly sending the request to server and on server - post successful validation of service ticket [proxy ticket passed] is giving error associated with "ASSERTION".
The proxy validation should entail that there is no generation of TGT or PGT further [that may be required for webapp , not stateless sessionless access to RESTful webservice] - it should validate the ticket and allow further. As of now - it is using a function that tends to successfully validate the PGT and then tries to generate associated TGT etc and fails.
So what parameters are to be parsed for successful proxy validation - which should be different from service ticket validation process of webapp.
Any Idea's on how we can proceed further?
Thank you and Best Regards
Ritesh