Federico, CAS redirects you to the "service" parameter passed to the login screen. "A" could pass "C"'s service URL, but then I am not sure how you will ever log into "A" ...
I am not sure what you are asking about with regards to a SAML token. Do you want to get attributes from CAS using the old /samlValidate endpoint? If you are able to use a more modern CAS, I would suggest using the /p3/serviceValidate or /p3/proxyValidate endpoints to use the native CAS attribute release. Thanks, Carl ----- Original Message ----- From: "Federico Paparoni" <[email protected]> To: [email protected] Sent: Tuesday, November 4, 2014 3:23:35 AM Subject: Re: [cas-user] CAS with User/Role webapp manager Hi Carl, Webapps partecipate in the same SSO session but users must access only through webapp C. Is it possible to change the callback url in webapp A/B, so after login CAS will redirect to C? Anyway I think is possible to change the logic flow on CAS to redirect to webapp C. Another question: if I correctly modify CAS flow how I can have a SAML token on webapp C ? Cheers, Federico Il 03/nov/2014 19:02 "Waldbieser, Carl" <[email protected]> ha scritto: > > Federico, > > If all your webapps participate in the same CAS SSO session, the > authentication issue seems to be solved. > Your issue, if I understand correctly, is that "A" and "B" need the user > to interact with "C" first. > > I think that is something you will need to handle at the application > level. "A" or "B" will have to be able to detect that "C" was never > visited and redirect to "C". "C" needs some way to tell "A" and "B" that > user has interacted with it, and transmit any relevant data to those apps. > > If "C" supported some kind of web service that "A" or "B" could pull from, > you might be able to do something like this: > > 1) User browses to "C" (or maybe is redirected from "A"). > 2) User redirected to CAS for authN. > 3) User redirected back to "C" which validates the CAS service ticket. > 4) User interacts with "C" which sets up some kind of local application > state. > 5) User follows link or is redirected to "A". > 6) "A" requires authN, so redirects to CAS, which sees the TGT. CAS > issues a ST and redirects back to "A". > 7) "A" validates and requests a proxy granting ticket. A issues a proxy > ticket to use the web service at "C". > 8) The web service at "C" validates the proxy ticket. Since the proxy > ticket is linked to a user, it looks up the stored > application state and responds to "A"'s request with that application > data. > > Would something like that work for your scenario? Without knowing more > about the nature of the services, I am not sure what would make sense. > > Thanks, > Carl > > ----- Original Message ----- > From: "Federico Paparoni" <[email protected]> > To: [email protected] > Sent: Monday, November 3, 2014 12:23:50 PM > Subject: Re: [cas-user] CAS with User/Role webapp manager > > The requirement is that user MUST interact directly with both C and A. > Ok so proxy authentication is useful only for those scenario I want to > protect some services without direct interaction of users. > Anything can be done using CAS for my scenario? > > Thanks, > > Federico > > > 2014-11-03 18:13 GMT+01:00 Waldbieser, Carl <[email protected]>: > > > Federico, > > > > When a user authenticates to "C", can C transparently get the data it > > needs from "A" or "B" if it can authenticate to those service on behalf > of > > the user? > > If so, then you could have CAS proxy authentication work that way, too. > > > > If the user needs to interact directly with both "C" and "A" (for > > example), then you don't want to use proxy authentication. > > > > Thanks, > > Carl > > > > ----- Original Message ----- > > From: "Federico Paparoni" <[email protected]> > > To: [email protected] > > Sent: Monday, November 3, 2014 12:03:59 PM > > Subject: Re: [cas-user] CAS with User/Role webapp manager > > > > Hi Carl, > > > > the user must pass through webapp C, because only there is the list of > > available apps for a user. An admin on webapp C will select which > > applications a user can access. In this way users don't bookmark webapp > A/B > > or even if they bookmark it the main entry point is webapp C. > > > > > > 2014-11-03 17:26 GMT+01:00 Waldbieser, Carl <[email protected]>: > > > > > > > > Federico, > > > > > > It sounds like your users should authenticate with CAS to webapp A or > B. > > > Those services should request proxy granting tickets for webapp C. > They > > > should then request proxy tickets for webapp C and attempt get the > user's > > > roles on a back channel. > > > > > > Your users would never browse to or see webapp C in the scenario I > > > described. Your other webapps would leverage webapp C to get the user > > role > > > information. > > > > > > Thanks, > > > Carl Waldbieser > > > ITS System Programmer > > > Lafayette College > > > > > > ----- Original Message ----- > > > From: "Federico Paparoni" <[email protected]> > > > To: [email protected] > > > Sent: Monday, November 3, 2014 11:12:56 AM > > > Subject: [cas-user] CAS with User/Role webapp manager > > > > > > Hi all, > > > > > > I have the following scenario: > > > > > > - CAS server > > > - webapp A > > > - webapp B > > > - webapp C : user/app/roles manager, an application that map roles to > > > user/app. > > > Using it i can enable user to enter in a specific application with a > list > > > of roles > > > > > > When a user tries to access to webapp A, if not authenticated, the > > > browser redirects > > > to CAS login page. The custom authentication should also retrieve the > > roles > > > associated with the user. Then the browser is redirected to webapp C, > > where > > > the user can see a list of link with enabled applications. > > > > > > I read the Proxy CAS Walkthrough ( > > > https://wiki.jasig.org/display/CAS/Proxy+CAS+Walkthrough) and some > > > other documentations > > > on possible architectures but I don't understand if myscenario is > > suitable > > > with a customization of CAS server. Ideas? > > > > > > Cheers, > > > > > > Federico > > > > > > -- > > > You are currently subscribed to [email protected] as: > > > [email protected] > > > To unsubscribe, change settings or access archives, see > > > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > > -- > > > You are currently subscribed to [email protected] as: > > > [email protected] > > > To unsubscribe, change settings or access archives, see > > > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > > > > > > > > -- > > Federico Paparoni > > > > Blog -- http://fpaparoni.wordpress.com/ > > Twitter -- http://twitter.com/fpaparoni > > > > -- > > You are currently subscribed to [email protected] as: > > [email protected] > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > > You are currently subscribed to [email protected] as: > > [email protected] > > To unsubscribe, change settings or access archives, see > > http://www.ja-sig.org/wiki/display/JSG/cas-user > > > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
