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. The another option can be to have an apache HTTPD - infront of CAS - that performs the OIDC - some thing like - https://apereo.github.io/cas/6.5.x/authentication/Trusted-Authentication.html 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 "Cas20 *WithoutProxyingValidation*Specification". 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=true ACTION: 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 On Mon, Jul 11, 2022 at 8:15 PM Ray Bon <r...@uvic.ca> wrote: > Ritesh, > > Can the service be modified to use OAuth2 or OIDC for > authorization/authentication instead of PGT? > > Ray > > On Sun, 2022-07-10 at 19:45 -0700, Ritesh Tripathi wrote: > > Notice: This message was sent from outside the University of Victoria > email system. Please be cautious with links and sensitive information. > > Folks, > > We have the following scenario: > > A. We have a web-app that is deployed in tomcat container and protected > via cas-client. > B. The browser based interaction all works well with authentication via > CAS Server. > C. We have an android app - that also authenticates with CAS via OIDC > protocol. [In the cas - user authenticates via delegated oAuth2 protocol > via gmail, so we don't have access to user password]. > D. In mobile - app - we are able to authenticate successfully and get the > userid. > E. The mobile app - needs to call the REST Web-service - from a URL that > is protected via CAS Client. [so both mobile app and web-app are talking to > same URL]. > F. Now - when we make calls to REST Web-service that is protected via CAS > from mobile app - we are redirected to login page. > > Since we don't have access to password of the user - we can't use the REST > Web-service for CAS to get the TGT for user and hence ST for the > rest-web-service. Alternatively - if we internally hard-code some user of > CAS to fetch the TGT and then ST, it add about 300 ms of additional time to > service calls and additional 2 calls to be made to fetch the data from REST > API for each API Call. > > This leaves us an option of proxy authentication. > > The issue is that we are unable to get the Proxy Granting Ticket for > mobile app - when we do authentication via OIDC Protocol. > > 1. Is it possible to get PGT for mobile app authentication via OIDC? > 2. Is there any other approach to solve the above scenario? > > Request you all to please give idea's about possible solutions to the > above situation. I am sure people would have solved the above challenge. > > Thank you for your support and time. > > Best Regards > > Ritesh > > > -- > > Ray Bon > Programmer Analyst > Development Services, University Systems > 2507218831 | CLE 019 | r...@uvic.ca > > I acknowledge and respect the lək̓ʷəŋən peoples on whose traditional > territory the university stands, and the Songhees, Esquimalt and WSÁNEĆ > peoples whose historical relationships with the land continue to this day. > > -- > - 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 a topic in the > Google Groups "CAS Community" group. > To unsubscribe from this topic, visit > https://groups.google.com/a/apereo.org/d/topic/cas-user/tqhfldU8ht8/unsubscribe > . > To unsubscribe from this group and all its topics, 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/ac5946cd9817aa4597f8c293870ad124e41f2848.camel%40uvic.ca > <https://groups.google.com/a/apereo.org/d/msgid/cas-user/ac5946cd9817aa4597f8c293870ad124e41f2848.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/CAGcP-QoKFyzxq-XJDQ-yFTxDMfUfThQ1XMVvFehvye%2BS539eGg%40mail.gmail.com.
