[cas-user] REST API exception

518 views
Skip to first unread message

Tim Robinson

unread,
Oct 18, 2012, 11:32:01 AM10/18/12
to cas-...@lists.jasig.org
I am having trouble activating the RESTful API on CAS 3.5.1.

Using the WAR overlay method to package CAS I added the following to pom.xml:

    <dependency>
            <groupId>org.jasig.cas</groupId>
            <artifactId>cas-server-integration-restlet</artifactId>
            <version>${cas.version}</version>
            <type>jar</type>
            <exclusions>
                <exclusion>
                   <groupId>org.springframework</groupId>
                   <artifactId>spring-web</artifactId>
                </exclusion>
                <exclusion>
                   <groupId>javax.servlet</groupId>
                   <artifactId>servlet-api</artifactId>
                </exclusion>
            </exclusions>
        </dependency>


Deploying the produced WAR on Tomcat 6 throws the following exception:

2012-10-18 11:02:54,257 ERROR [com.noelios.restlet.ext.spring.RestletFrameworkServlet] - <Context initialization failed>
org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'root' defined in ServletContext resource [/WEB-INF/restlet-servlet.xml]: Cannot create inner bean 'org.restlet.ext.spring.SpringFinder#68dd6317' of type [org.restlet.ext.spring.SpringFinder] while setting bean property 'attachments' with key [TypedStringValue: value [/tickets], target type [null]]; nested exception is org.springframework.beans.factory.BeanCreationException: Error creating bean with name 'org.restlet.ext.spring.SpringFinder#68dd6317' defined in ServletContext resource [/WEB-INF/restlet-servlet.xml]: Instantiation of bean failed; nested exception is java.lang.StackOverflowError
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveInnerBean(BeanDefinitionValueResolver.java:281)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveValueIfNecessary(BeanDefinitionValueResolver.java:120)
at org.springframework.beans.factory.support.BeanDefinitionValueResolver.resolveManagedMap(BeanDefinitionValueResolver.java:378)

Has anyone seen this before?  Perhaps a dependency/version issue?  Playing with CAS is my first foray into Java dev so any help would be appreciated.

Thanks.
Tim



-- 
You are currently subscribed to cas-...@lists.jasig.org as: jasig-cas-user...@googlegroups.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Scott Battaglia

unread,
Oct 18, 2012, 11:39:03 PM10/18/12
to cas-...@lists.jasig.org
That's a new one.  Do you have a Maven overlay project you can zip up and include here?  I'll try it out if you do (remove any secret passwords, etc. :-))


-- 
You are currently subscribed to cas-...@lists.jasig.org as: scott.b...@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Tim Robinson

unread,
Oct 19, 2012, 11:39:16 AM10/19/12
to cas-...@lists.jasig.org
Attached a sanitized and mvn clean version of my overlay project. Thanks
for taking a look.


Tim
>tim.ro...@humedica.com
build.zip

Tim Robinson

unread,
Oct 19, 2012, 2:06:08 PM10/19/12
to cas-...@lists.jasig.org
Thanks Pedro. This worked for me.


On 10/19/12 12:33 PM, "Pedro Costa" <pedrof...@gmail.com> wrote:

>Hi Tim
>
>I have seen this one, the cglib-full jar was being included in
>the packaged war for some reason. you need to remove it.
>
>I used:
>
><overlays>
> <overlay>
>
><groupId>org.jasig.cas</groupId>
>
><artifactId>cas-server-webapp</artifactId>
> <excludes>
> <!--
>This breaks the REST API in tomcat -->
>
><exclude>WEB-INF/lib/cglib-full-*.jar</exclude>
> </excludes>
> </overlay>
> </overlays>
>
>in the war plugin configuration
>
>Cheers
>Pedro
>
>2012/10/19 Tim Robinson <Tim.Ro...@humedica.com>:
>>pedrof.c...@gmail.com

Richard Yang

unread,
Oct 19, 2012, 2:46:27 PM10/19/12
to cas-...@lists.jasig.org
I am calling cas Restful API to generate a TGT. I would like to store this as the valie in the
CASTGC. But the domain of my application is different from that of the cas server. So can I foul the cas server to make it think this is a valid cookie?
 
Otherwise, I had to generate a ST for each service request programmatically using Restful api. This approach has its drawback as it involves application code to manage the ST.

Andrew Petro

unread,
Oct 19, 2012, 3:14:44 PM10/19/12
to cas-...@lists.jasig.org
Richard,

By design, only CAS can set and read the CAS ticket granting cookie.  This is important to the security of using CAS, since if your CAS TGC was readable more widely (by, say, your application on a different domain), then applications able to read the cookie could read it and use it to craft their own requests to get service tickets in the name of the user.  That is, this would enable illicit delegation.

So.  What are you trying to do?  The RESTful API is more intended for your application to authenticate as itself to get a TGT to obtain STs authenticating itself to other services.  If you want to be authenticating end users, then the intent of the CAS design is for your application to send those users to CAS to log in to CAS directly, obtain a ST to log in to your application, and then your application can obtain a PGT from that if you need to be getting PTs to authenticate to other applications on the user's behalf.

Hope this helps,

Andrew


On Fri, Oct 19, 2012 at 2:46 PM, Richard Yang <rya...@yahoo.com> wrote:
I am calling cas Restful API to generate a TGT. I would like to store this as the valie in the
CASTGC. But the domain of my application is different from that of the cas server. So can I foul the cas server to make it think this is a valid cookie?
 
Otherwise, I had to generate a ST for each service request programmatically using Restful api. This approach has its drawback as it involves application code to manage the ST.
-- 
You are currently subscribed to cas-...@lists.jasig.org as: ape...@unicon.net

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Yang, Richard

unread,
Oct 19, 2012, 3:54:35 PM10/19/12
to cas-...@lists.jasig.org

Hi, Andrew:

 

Thanks for your quick response.

 

My problem right now is that I don’t want to use cas as SSO. I use cas just because the third party use cas to validate request from us to them. We have our own login page.

That is why I use cas restful api to generate TGT and subsequently generate ST. This all work fine except that the ST is used only once and thrown away. If the client (browser) refreshes, it needs to get a new url with new ST appeneded. This created performance issue.

Is there any way to config cas not to throw away ST. Instead make is valid for a period of time?

 

Please let me know.

 

Thanks.

 

Richard

-- 
You are currently subscribed to cas-...@lists.jasig.org as: Richar...@pearson.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Dmitriy Kopylenko

unread,
Oct 19, 2012, 4:50:57 PM10/19/12
to cas-...@lists.jasig.org



Is there any way to config cas not to throw away ST. Instead make is valid for a period of time?

 

 

From: Andrew Petro [mailto:ape...@unicon.net]
Sent: Friday, October 19, 2012 2:15 PM
To: cas-...@lists.jasig.org
Subject: Re: [cas-user] Can yo manually set CASTGC cookie manually (httpservletrsponse) to a different domain

 

Richard,

 

By design, only CAS can set and read the CAS ticket granting cookie.  This is important to the security of using CAS, since if your CAS TGC was readable more widely (by, say, your application on a different domain), then applications able to read the cookie could read it and use it to craft their own requests to get service tickets in the name of the user.  That is, this would enable illicit delegation.

 

So.  What are you trying to do?  The RESTful API is more intended for your application to authenticate as itself to get a TGT to obtain STs authenticating itself to other services.  If you want to be authenticating end users, then the intent of the CAS design is for your application to send those users to CAS to log in to CAS directly, obtain a ST to log in to your application, and then your application can obtain a PGT from that if you need to be getting PTs to authenticate to other applications on the user's behalf.

 

Hope this helps,

 

Andrew

 

On Fri, Oct 19, 2012 at 2:46 PM, Richard Yang <rya...@yahoo.com> wrote:

I am calling cas Restful API to generate a TGT. I would like to store this as the valie in the

CASTGC. But the domain of my application is different from that of the cas server. So can I foul the cas server to make it think this is a valid cookie?

 

Otherwise, I had to generate a ST for each service request programmatically using Restful api. This approach has its drawback as it involves application code to manage the ST.

-- 
You are currently subscribed to cas-...@lists.jasig.org as: ape...@unicon.net
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

 

-- 
You are currently subscribed to cas-...@lists.jasig.org as: Richar...@pearson.com
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
-- 
You are currently subscribed to cas-...@lists.jasig.org as: dmitriy....@gmail.com

To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user

Andrew Petro

unread,
Oct 19, 2012, 5:25:37 PM10/19/12
to cas-...@lists.jasig.org
But you probably shouldn't configure the ST to be multiply validatable (as opposed to just one-time-use).

CAS is an authentication broker, not a session manager.

So, your application (or the end user) can use an ST once to log in to an application.  Great.  But then that application should establish a traditional cookie-mediated web application session (for the end user) or participate in some reasonable web service authentication regime (for service-to-service calls).

One option would be for the application to itself continue to accept the ST as a lightweight adhoc session identifier.  Spring Security provides support for this.  In the case where your application is using this ST to access a web service directly.

So, yes, you can configure an ST to be longer-lived and multiply-usable, in CAS ticket expiration policy configuration.  And you probably shouldn't be needing to do either of those configuration changes.

Hope this helps,

Andrew
Reply all
Reply to author
Forward
0 new messages