I have two java web modules:

- The first one is acccessed directly by the user and acting as CAS-Proxy
(proxy.war)

- The second one is acting as the proxied service (service.war)

- "proxy.war" is accessing "service.war" via REST calls of type GET.

The Proxy CAS mecanism is working correctlty. I got the tickets:
TicketGrantingTicket, PgtIOU, ProxyGrantingTicket.

 

 

Before that "proxy.war" invokes  "service.war", I added the code in
"proxy.war" asking for ProxyTicket.

>>>String  ticket = principal.getProxyTicketFor(targetURL); <<<  

   with targetURL =  https:// <https://%3chost%3e:%3cport%3e/service/rest>
<host>:<port>/service/rest   /* This is the root context of all REST calls*/

 

As all the target sevices are REST calls of type GET, then each call will be
suffixed according to is arguments:

For example, it will be "https://
<https://%3chost%3e:%3cport%3e/service/rest/path1/argument1>
<host>:<port>/service/rest/path1/argument1" for a call and "https://
<https://%3chost%3e:%3cport%3e/service/rest/path2/argument2>
<host>:<port>/service/rest/path2/argument2" for another.

 

 

1/ Should I ask for a ticket for each REST call ?

   Ex: principal.getProxyTicketFor("https://
<https://%3chost%3e:%3cport%3e/service/rest/path1/argument1>
<host>:<port>/service/rest/path1/argument1") for a call

       principal.getProxyTicketFor("https://
<https://%3chost%3e:%3cport%3e/service/rest/path2/argument2>
<host>:<port>/service/rest/path2/argument2") for another call

 

You can, but you should try to avoid this.   What you have to remember is
that once you access a URL with a proxy ticket (PT), then the authentication
information can be stored in the session (I think that the Java CAS client
does this by default).  Therefore, as long as your client (insie the proxy)
can store cookies, it can make further access to the "service" web
application without getting additional tickets.  The trick is that you need
to maintain the cookie store (you could store it in the user's session of
the "proxy" service).

 

2/ Or, is it possible to get a unique ticket valid to a patten of URLs ? 

   If I use the PT issued by principal.getProxyTicketFor("https://
<https://%3chost%3e:%3cport%3e/service/rest> <host>:<port>/service/rest"),

   this ticket won't be validated
(/poxyvalidate?ticket=<PT>&service=https://<host>:<port>/service/rest/pathi/
argumenti

 

There are two different issues.

 

1) The ticket will be good for one time use only by default.   However, the
session that is established by your servlet container will apply to the
entire "service" web application.  So you get the ticket for one URI and you
use the resulting session for the other accesses.

 

2) Whether you request the ticket for the specific URI or you request a
generic service will depend on how you have configured the java cas client.

 

from:
https://wiki.jasig.org/display/CASC/Configuring+the+Jasig+CAS+Client+for+Jav
a+in+the+web.xml

 

.         service - the service URL to send to the CAS server, e.g.
<https://localhost:8443/yourwebapp/index.html>
https://localhost:8443/yourwebapp/index.html

.         serverName - the server name of the server this application is
hosted on. Service URL will be dynamically constructed using this, i.e.
<https://localhost:8443/> https://localhost:8443 (you must include the
protocol, but port is optional if it's a standard port).

 

If you set up the client with the "service" parameter, then you will always
getProxyTicketFor() that service URI no matter which URI you are accessing.

 

If you set up the client with the "serverName" parameter, then you will
getProxyTicketFor() that the specific URI.

 

I've always set up clients with the "serverName" parameter.   I think that
if you use "service" and go directly against you rest service with the
browser, the initial call that requires the service ticket will always get
redirected to the "service" URI.

 

 

   What is wrong with what I'm doing ?

 

 

Thanks. 

 

Alf.

 

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

Attachment: smime.p7s
Description: S/MIME cryptographic signature

Reply via email to