Nabble - CAS Dev

JA-SIG Fall 2008 Unconference - Registration is Open

2008-07-17T10:50:36Z

REGISTER NOW FOR THE JA-SIG FALL 2008 UNCONFERENCE at UNIVERSITY OF
WISCONSIN-MADISON

- Registration fee for the October 2008 JA-SIG Unconference:
$175/Members, $225/Non-Members
- Nightly rate at the historic Edgewater Hotel: $129
- Two-and-a-half days talking, learning, teaching, planning, coding,
and hanging out with your peers - and with the uPortal, CAS, Fluid,
JSR-168, SpringMVC experts: Priceless!

NEW INFORMATION! HOW TO REGISTER!

DATES:
October 6, 2008, 9am to October 8, 2008, noon
October 9-10, developer meetings and optional post-conference activities

PLACE:
University of Wisconsin-Madison, Pyle Center, 702 Langdon Street,
Madison, WI 53706,
Front Desk: 608-262-1122

REGISTRATION FEE:
$175 - JA-SIG Members
$225 - Non-Members
(Includes Breakfast, Mon/Tue Lunch, and Snacks)
Register here:
https://www.concentra-cms.com/register/start.action?confId=34

ACCOMMODATIONS:
Edgewater Hotel, 666 Wisconsin Avenue, Madison, Wisconsin 53703
$129/single/night
800•922•5512 (www.theedgewater.com)
Make sure you ask for the JA-SIG room block and rate!
Hotel registration not available by web for this event.

WHAT'S AN UNCONFERENCE?

"An unconference is a conference where the content of the sessions is
driven and created by the participants, generally day-by-day during
the course of the event, rather than by a single organizer, or small
group of organizers, in advance."
-Wikipedia

JA-SIG has always been about people coming together to share and learn
in an open environment, and this is what an "unconference" is all
about. Many attendees at last year's unconference said it was their
favorite event of the year.

The October event will provide both spontaneous and planned
opportunities to collaborate on community initiatives and
topics.

WHAT ARE WE GOING TO DO?

It's up to you! Ideas people are talking about so far include the
following:

* Lightning Talks - Volunteers talk for up to 10 minutes.
Any topic goes.
* Code Clinics - Bring your uPortal, portlet, or CAS code or problem
and work on it with Core developers
* Screencast Factory - Show off your work while a facilitator captures
it to share with the community.
* Designer/Developer collaborations
* Strategic Planning - What should JA-SIG be focused on next year? In
three years? Join the conversation.
* How-to's. How-not-to's. Tips and techniques.
* See a list of ideas for activities and add your own:
http://www.ja-sig.org/wiki/x/BBTP

As part of the un-conference format the final schedule will be
determined in real-time, interactively with the attendees.

OK, I'M INTERESTED! WHAT SHOULD I DO NEXT?

If you're planning to join us, please do the following:

1. Register for the Unconference right here:
https://www.concentra-cms.com/register/start.action?confId=34
2. Visit and Add your Name on the Unconference Planning Site on
the JA-SIG wiki. This is a great place to indicate your
interests---what you'd like to discuss, learn, share or teach:
http://www.ja-sig.org/wiki/x/DRTP
3. Call the Edgewater Hotel to reserve a room: 800•922•5512
4. Make travel arrangements. Tips are available here:
http://www.ja-sig.org/wiki/x/wRjP

See you at the JA-SIG Unconference,
The Fall 2008 Unconference Organizers

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: [uportal-steering-committee] We Like Your Roadmap

2008-07-16T16:07:58Z

Sounds good. Let's see how things develop. Looking forward to the
historic meeting of the steering committees. :-)

-JJM

On Wed, Jul 16, 2008 at 2:08 PM, Scott Battaglia
<scott.battaglia@...> wrote:

> I think the best option would be a face-to-face* session at the October
> JASIG Unconference. This would give us time to get some more revisions on
> our road map, especially with the upcoming phone conference call (which I
> think you're attending). It would also give us time to continue to flesh
> out the governance model which is on our road map, that way if something
> comes from it, it would be the CAS governing/steering committee meeting with
> the uPortal steering committee ;-)
>
> -Scott
>
> * Face-to-face would clearly be pending management approval of attending the
> JASIG Unconference, as well as not having any scheduled exams. Alternatives
> include video-conferencing for those who were unable to attend the
> conference.
>
>
>
> On Wed, Jul 16, 2008 at 12:13 PM, Jonathan Markow <jjmarkow@...>
> wrote:
>>
>> Excellent idea. Are you thinking of a particular forum to kickstart
>> that discussion?
>> Some possibilities:
>> 1. Interested CAS committers could join a uPortal Steering Committee
>> call next month
>> 2. Face to face session at the October JASIG Unconference
>> 3. Both of the above.
>>
>> -JJM
>>
>> On Wed, Jul 16, 2008 at 12:01 PM, Scott Battaglia
>> <scott.battaglia@...> wrote:
>> > Jonathan,
>> >
>> > As an addition to the two projects having their individual road maps, it
>> > may
>> > be helpful to have a discussion around any joint road map that might be
>> > necessary.
>> >
>> > -Scott
>> >
>> > -Scott Battaglia
>> > PGP Public Key Id: 0x383733AA
>> > LinkedIn: http://www.linkedin.com/in/scottbattaglia
>> >
>> > On Tue, Jul 15, 2008 at 5:13 PM, Scott Battaglia
>> > <scott.battaglia@...>
>> > wrote:
>> >>
>> >> Cool! If you can think of any improvements to the representation of
>> >> the
>> >> data let us know!
>> >>
>> >> -Scott
>> >>
>> >> On Tue, Jul 15, 2008 at 5:07 PM, Jonathan Markow <jjmarkow@...>
>> >> wrote:
>> >>>
>> >>> CAS team:
>> >>>
>> >>> We like the work you've been doing on the CAS roadmap, and we plan to
>> >>> adopt the format for uPortal too. Also, it strikes us as beneficial
>> >>> to the community for both of us to be using the same format, so if you
>> >>> decide to modify yours at some point, please keep us posted.
>> >>>
>> >>> Thanks!
>> >>> Jonathan Markow (on behalf of the uPortal Project Steering Committee)
>> >>> _______________________________________________
>> >>> cas-dev mailing list
>> >>> cas-dev@...
>> >>> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>> >>
>> >
>> >
>> > _______________________________________________
>> > cas-dev mailing list
>> > cas-dev@...
>> > http://tp.its.yale.edu/mailman/listinfo/cas-dev
>> >
>> >
>> _______________________________________________
>> cas-dev mailing list
>> cas-dev@...
>> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: We Like Your Roadmap

2008-07-16T11:08:59Z

I think the best option would be a face-to-face* session at the October JASIG Unconference. This would give us time to get some more revisions on our road map, especially with the upcoming phone conference call (which I think you're attending). It would also give us time to continue to flesh out the governance model which is on our road map, that way if something comes from it, it would be the CAS governing/steering committee meeting with the uPortal steering committee ;-)

-Scott

* Face-to-face would clearly be pending management approval of attending the JASIG Unconference, as well as not having any scheduled exams. Alternatives include video-conferencing for those who were unable to attend the conference.

On Wed, Jul 16, 2008 at 12:13 PM, Jonathan Markow <jjmarkow@...> wrote:

Excellent idea. Are you thinking of a particular forum to kickstart
that discussion?
Some possibilities:
1. Interested CAS committers could join a uPortal Steering Committee
call next month
2. Face to face session at the October JASIG Unconference
3. Both of the above.

-JJM

On Wed, Jul 16, 2008 at 12:01 PM, Scott Battaglia

<scott.battaglia@...> wrote:
> Jonathan,
>
> As an addition to the two projects having their individual road maps, it may
> be helpful to have a discussion around any joint road map that might be
> necessary.
>
> -Scott
>
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>
> On Tue, Jul 15, 2008 at 5:13 PM, Scott Battaglia <scott.battaglia@...>
> wrote:
>>
>> Cool! If you can think of any improvements to the representation of the
>> data let us know!
>>
>> -Scott
>>
>> On Tue, Jul 15, 2008 at 5:07 PM, Jonathan Markow <jjmarkow@...>
>> wrote:
>>>
>>> CAS team:
>>>
>>> We like the work you've been doing on the CAS roadmap, and we plan to
>>> adopt the format for uPortal too. Also, it strikes us as beneficial
>>> to the community for both of us to be using the same format, so if you
>>> decide to modify yours at some point, please keep us posted.
>>>
>>> Thanks!
>>> Jonathan Markow (on behalf of the uPortal Project Steering Committee)
>>> _______________________________________________
>>> cas-dev mailing list
>>> cas-dev@...
>>> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>>
>
>
> _______________________________________________
> cas-dev mailing list
> cas-dev@...
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: We Like Your Roadmap

2008-07-16T09:13:41Z

Excellent idea. Are you thinking of a particular forum to kickstart
that discussion?
Some possibilities:
1. Interested CAS committers could join a uPortal Steering Committee
call next month
2. Face to face session at the October JASIG Unconference
3. Both of the above.

-JJM

On Wed, Jul 16, 2008 at 12:01 PM, Scott Battaglia
<scott.battaglia@...> wrote:

> Jonathan,
>
> As an addition to the two projects having their individual road maps, it may
> be helpful to have a discussion around any joint road map that might be
> necessary.
>
> -Scott
>
> -Scott Battaglia
> PGP Public Key Id: 0x383733AA
> LinkedIn: http://www.linkedin.com/in/scottbattaglia
>
> On Tue, Jul 15, 2008 at 5:13 PM, Scott Battaglia <scott.battaglia@...>
> wrote:
>>
>> Cool! If you can think of any improvements to the representation of the
>> data let us know!
>>
>> -Scott
>>
>> On Tue, Jul 15, 2008 at 5:07 PM, Jonathan Markow <jjmarkow@...>
>> wrote:
>>>
>>> CAS team:
>>>
>>> We like the work you've been doing on the CAS roadmap, and we plan to
>>> adopt the format for uPortal too. Also, it strikes us as beneficial
>>> to the community for both of us to be using the same format, so if you
>>> decide to modify yours at some point, please keep us posted.
>>>
>>> Thanks!
>>> Jonathan Markow (on behalf of the uPortal Project Steering Committee)
>>> _______________________________________________
>>> cas-dev mailing list
>>> cas-dev@...
>>> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>>
>
>
> _______________________________________________
> cas-dev mailing list
> cas-dev@...
> http://tp.its.yale.edu/mailman/listinfo/cas-dev
>
>

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: We Like Your Roadmap

2008-07-16T09:01:05Z

Jonathan,

As an addition to the two projects having their individual road maps, it may be helpful to have a discussion around any joint road map that might be necessary.

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Tue, Jul 15, 2008 at 5:13 PM, Scott Battaglia <scott.battaglia@...> wrote:

Cool! If you can think of any improvements to the representation of the data let us know!

-Scott

On Tue, Jul 15, 2008 at 5:07 PM, Jonathan Markow <jjmarkow@...> wrote:

CAS team:

We like the work you've been doing on the CAS roadmap, and we plan to
adopt the format for uPortal too. Also, it strikes us as beneficial
to the community for both of us to be using the same format, so if you
decide to modify yours at some point, please keep us posted.

Thanks!
Jonathan Markow (on behalf of the uPortal Project Steering Committee)
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: We Like Your Roadmap

2008-07-15T14:13:30Z

Cool! If you can think of any improvements to the representation of the data let us know!

-Scott

On Tue, Jul 15, 2008 at 5:07 PM, Jonathan Markow <jjmarkow@...> wrote:

CAS team:

We like the work you've been doing on the CAS roadmap, and we plan to
adopt the format for uPortal too. Also, it strikes us as beneficial
to the community for both of us to be using the same format, so if you
decide to modify yours at some point, please keep us posted.

Thanks!
Jonathan Markow (on behalf of the uPortal Project Steering Committee)
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

We Like Your Roadmap

2008-07-15T14:07:36Z

CAS team:

We like the work you've been doing on the CAS roadmap, and we plan to
adopt the format for uPortal too. Also, it strikes us as beneficial
to the community for both of us to be using the same format, so if you
decide to modify yours at some point, please keep us posted.

Thanks!
Jonathan Markow (on behalf of the uPortal Project Steering Committee)
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

CAS 3.2.1.1 Release and CAS 3.3-RC2 Release

2008-07-15T08:51:51Z

All,

First, the most important, we've released a minor point release of version 3.2.1.1 which addresses an opportunity to inject HTML into the logout page via the url parameter. You can't hijack CAS sessions or anything with but you can create some really funky HTML pages which could trick your users if they're not paying attention. If you've based your logout page at your local institution off of the "example default" pages then you should update your logout page (just to be safe we also updated the "confirm view" also. Thanks to Romain Bourgue for identifying this. There are no other changes in the 3.2.1.1 release.

We've also released CAS 3.3-RC2. If you've been keeping track we last left off at 3.2.2-RC1. We've made some exciting additions such as Terracotta support, Memcache Support, updated RESTful support, and a lot of minor bug fixes. Because of a change to an internal property on the tickets (changing from Atomic Boolean to boolean) and its affect on the JPATicketRegistry we bumped up the version to 3.3.

You can download both releases from http://www.ja-sig.org/products/cas/downloads/

Thanks!
-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: 2.1.1 Java client w/ attribute support

2008-07-15T06:47:17Z

Sean,

Your best bet is to check here:
http://code.google.com/p/legacy-java-cas-client/

Any work being done on that particular CAS client would be done there. I'm not sure if they are doing much beyond maintenance though.

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Tue, Jul 15, 2008 at 9:37 AM, Sean R. McNamara <sean.r.mcnamara@...> wrote:

I posted this a few days ago but didn't hear anything back. I modified
the 2.1.1 Java client to support attribute release by the server. Is
there anyone maintaining this release? Is anyone interested in the
code? I'd like to contribute it back, if there's any interest. Please
see my message from a few days ago for details.

Thanks.

..Sean.
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: Memcache ticket registry

2008-07-15T06:40:57Z

Despite the fact that others have been successful in deploying JBossCache we experienced significant scaling issues locally. I'm not sure what the cause was, whether it was a limitation of JBossCache or our network topology but we decided to see what else was available. We've had good luck with memcached (patched to be repcache) and we're looking at deploying that barring any further testing indicating that there's a problem.

Using LoadRunner we've run some pretty heavy load tests with 250, 300, 400 and 500 vusers (the max our license has) for about a half hour each. We also did a 2.5 day "soak" test that generated about 120 GB of traffic (our network people loved us that weekend).

As we get further along I'll be sure to pass any information along to the list (especially if we end up not going with this ;-))

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Tue, Jul 15, 2008 at 7:01 AM, Arnaud Lesueur <arnaud.lesueur@...> wrote:

Hi Scott,

I thought Rutgers was migrating to JBossCache. Did you experimented any issue with it ? What is going to be the final architecture at your side ?
Or is it simply a PoC for comparison with JBossCache (or even Terracota in future) ?

Regards,

Arnaud Lesueur

On Mon, Jul 14, 2008 at 5:58 PM, Scott Battaglia <scott.battaglia@...> wrote:

All,

As part of the next upcoming release (most likely to be renamed to 3.3 instead of 3.2.2), we're adding Memcache support for those who want to use it (we've seen good performance with it here at RU in our testing):

The code is in SVN but not in any release yet, though I've posted some documentation here:
http://www.ja-sig.org/wiki/display/CASUM/MemcacheTicketRegistry

If anyone who has memcache experience can test it out that would be great. We've hit it pretty hard here but we're only one place. We also did a 2.5 day "soak" test in addition to stress testing.

Thanks
-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

--
Arnaud Lesueur

LinkedIn: http://www.linkedin.com/in/lesueur

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

2.1.1 Java client w/ attribute support

2008-07-15T06:37:28Z

I posted this a few days ago but didn't hear anything back. I modified
the 2.1.1 Java client to support attribute release by the server. Is
there anyone maintaining this release? Is anyone interested in the
code? I'd like to contribute it back, if there's any interest. Please
see my message from a few days ago for details.

Thanks.

..Sean.
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: Memcache ticket registry

2008-07-15T04:01:08Z

Hi Scott,

I thought Rutgers was migrating to JBossCache. Did you experimented any issue with it ? What is going to be the final architecture at your side ?
Or is it simply a PoC for comparison with JBossCache (or even Terracota in future) ?

Regards,

Arnaud Lesueur

On Mon, Jul 14, 2008 at 5:58 PM, Scott Battaglia <scott.battaglia@...> wrote:

All,

As part of the next upcoming release (most likely to be renamed to 3.3 instead of 3.2.2), we're adding Memcache support for those who want to use it (we've seen good performance with it here at RU in our testing):

The code is in SVN but not in any release yet, though I've posted some documentation here:
http://www.ja-sig.org/wiki/display/CASUM/MemcacheTicketRegistry

If anyone who has memcache experience can test it out that would be great. We've hit it pretty hard here but we're only one place. We also did a 2.5 day "soak" test in addition to stress testing.

Thanks
-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

--
Arnaud Lesueur

LinkedIn: http://www.linkedin.com/in/lesueur

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: customizing the Login view

2008-07-14T19:26:42Z

I don't know for sure. My guess would be you would need to use one of the other tags. You may be able to usethe hasBindErrors tag if you know the path to the errors (which *might* be "credentials" but don't quote me on that one.)

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Thu, Jul 10, 2008 at 7:03 PM, Patrick Berry <pberry@...> wrote:

Is there a way to have the <form:error> above the <form:form> in the login view jsp?

Found a couple of questions like this on the google, but they were unanswered.

Pat

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: CAS 4 Roadmap Planning (Call for Participation)

2008-07-14T12:47:37Z

We have assembled a draft agenda for the roadmap planning call which is
included below for your information. If you are interested in
participating but have not yet let me know, it is not too late to do so.

[1] Direction & Requirements
- Next Steps for the CAS 3.x branch
- What are we looking for in a CAS4?
<http://www.ja-sig.org/wiki/display/CAS/CAS+Vision+and+Roadmap>
* Integration with Existing Systems
* Features / Use Cases
* Relationship to Existing Architecture

[2] Project Resources
- How the to-do list gets done
* Implementers
* Sponsors?
* Grants?
- Support
* Mailing lists
* Documentation

[3] Governance Model
- Comments on/discussion of model
<http://www.ja-sig.org/wiki/display/CAS/Governance+Model>

-Benn-

Benn Oshrin <benjamin.oshrin@...> wrote on June 24, 2008
11:16:17 AM -0400:

] As you may already know, we have begun a draft of a development
] roadmap for CAS 3.x and 4.
]
] <http://www.ja-sig.org/wiki/display/CAS/CAS+Vision+and+Roadmap>
]
] We would like to start a discussion to help revise this roadmap and to
] identify the issues around it such as potential architecture changes,
] etc. As a first step, we are looking for other interested parties
] to join a conference call sometime in the near future.
]
] If you are interested in participating, please let me know, and I
] will forward more information once we have it.
]
] Thanks,
]
] -Benn-

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Memcache ticket registry

2008-07-14T08:58:11Z

All,

As part of the next upcoming release (most likely to be renamed to 3.3 instead of 3.2.2), we're adding Memcache support for those who want to use it (we've seen good performance with it here at RU in our testing):

The code is in SVN but not in any release yet, though I've posted some documentation here:
http://www.ja-sig.org/wiki/display/CASUM/MemcacheTicketRegistry

If anyone who has memcache experience can test it out that would be great. We've hit it pretty hard here but we're only one place. We also did a 2.5 day "soak" test in addition to stress testing.

Thanks
-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

customizing the Login view

2008-07-10T16:03:59Z

Is there a way to have the <form:error> above the <form:form> in the login view jsp?

Found a couple of questions like this on the google, but they were unanswered.

Pat

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Update to yale Java client to accept attributes

2008-07-10T09:01:47Z

Hi all,

I modified the Yale 2.1.1 CAS client to accept attributes handed back by
the CAS server.

It will accept anything in the serviceResponse formatted such as:

<cas:serviceResponse xmlns:cas='http://www.yale.edu/tp/cas'>
<cas:authenticationSuccess>
<cas:user>Sean R. McNamara</cas:user>

<cas:attribute name="loginType" value="USERPASS"/>

<cas:attribute name="name" value="Sean R. McNamara"/>

<cas:attribute name="affil" value="DART"/>

</cas:authenticationSuccess>
</cas:serviceResponse>

and make the values available in the session named as:

edu.yale.its.tp.cas.client.filter.attribute.<attribute name>
e.g. edu.yale.its.tp.cas.client.filter.attribute.name or
edu.yale.its.tp.cas.client.filter.attribute.affil or
edu.yale.its.tp.cas.client.filter.loginType (from the above example)

it also makes a HashMap available of all the values at
edu.yale.its.tp.cas.client.filter.attribute

Another feature I added was to allow the filter to override the value of
edu.yale.its.tp.cas.client.filter.user in web.xml

by setting an init-param such as:

<init-param>

<param-name>edu.yale.its.tp.cas.client.filter.idattribute</param-name>

<param-value>edu.yale.its.tp.cas.client.filter.attribute.name</param-value>
</init-param>

I would like to contribute this code back to the project. How should I
go about this?

Thanks!

..Sean.

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: Improvement suggestion for AbstractTicketValidationFilter

2008-07-09T04:41:09Z

Manfred,

If you can, please enter both of your emails to the list as issues in the JIRA tracker: http://www.ja-sig.org/issues for the CAS client project.

Thanks!
-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Wed, Jul 9, 2008 at 3:03 AM, Manfred Duchrow <manfred.duchrow@...> wrote:

- Better support of user friendly error pages (instead of stack trace).
It is not possible to redirect from within the onFailedValidation() to an
error page which is more user friendly than a stack trace.
It would be helpful if onFailedValidation() would return a boolean
telling the caller method to return immediately (true) or continue (false).

- Method onFailedValidation() does not get the catched exception.
Therefore it is not possible to react differently on different exceptions.
At least there are two different reasons for getting a
TicketValidationException:
1) Communication with CAS server fails
2) The validation of the ticket fails (as returned by CAS server response)

- In case of a TicketValidationException method doFilter() either throws a
ServletException or continues executing the next filter in the chain.
The latter is probably a security hole and simply happens if init-param
exceptionOnValidationFailure=false ist set.

To enable redirect to an error page we modified the code of class
AbstractTicketValidationFilter in the following way:

Added new template method:
/**
* Template method that gets executed if validation fails.
* This method is called right after the exception is caught from the ticket
validator
* but before {@link #onFailedValidation(HttpServletRequest,
HttpServletResponse)} and before
* any of the processing of the exception occurs.
* If this method returns true it signals that validation failure has been
handled
* sufficiently and the filter execution must be ended immediately.
* By returning false it signals that processing can be continued (as in
previous versions).
*
* @param request the HttpServletRequest.
* @param response the HttpServletResponse.
* @param validationException The exception that was thrown to signal
validation failure
* @return true to return immediately from filter execution, false to
continue processing (default is false)
*/
protected boolean handleFailedValidation(final HttpServletRequest request,
final HttpServletResponse response,
final TicketValidationException validationException )
{
return false ; // Default is to continue
}

Changed doFilter(..)
....
} catch (final TicketValidationException e) {
// ---------------- START NEW CODE ------------------
if (handleFailedValidation(request, response, e))
{
return ;
}
// ---------------- END NEW CODE ------------------

response.setStatus(HttpServletResponse.SC_FORBIDDEN);
log.warn(e, e);

if (this.exceptionOnValidationFailure) {
throw new ServletException(e);
}
}
....

Generally I don't think it is a good approach to patch CAS code.
Is it possible to get that or something similar into CAS Client?

This refers to CAS Client 3.1.3

Cheers,
Manfred

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Improvement suggestion for AbstractTicketValidationFilter

2008-07-09T00:03:06Z

- Better support of user friendly error pages (instead of stack trace).
It is not possible to redirect from within the onFailedValidation() to an
error page which is more user friendly than a stack trace.
It would be helpful if onFailedValidation() would return a boolean
telling the caller method to return immediately (true) or continue (false).

- Method onFailedValidation() does not get the catched exception.
Therefore it is not possible to react differently on different exceptions.
At least there are two different reasons for getting a
TicketValidationException:
1) Communication with CAS server fails
2) The validation of the ticket fails (as returned by CAS server response)

- In case of a TicketValidationException method doFilter() either throws a
ServletException or continues executing the next filter in the chain.
The latter is probably a security hole and simply happens if init-param
exceptionOnValidationFailure=false ist set.

To enable redirect to an error page we modified the code of class
AbstractTicketValidationFilter in the following way:

Added new template method:
/**
* Template method that gets executed if validation fails.
* This method is called right after the exception is caught from the ticket
validator
* but before {@link #onFailedValidation(HttpServletRequest,
HttpServletResponse)} and before
* any of the processing of the exception occurs.
* If this method returns true it signals that validation failure has been
handled
* sufficiently and the filter execution must be ended immediately.
* By returning false it signals that processing can be continued (as in
previous versions).
*
* @param request the HttpServletRequest.
* @param response the HttpServletResponse.
* @param validationException The exception that was thrown to signal
validation failure
* @return true to return immediately from filter execution, false to
continue processing (default is false)
*/
protected boolean handleFailedValidation(final HttpServletRequest request,
final HttpServletResponse response,
final TicketValidationException validationException )
{
return false ; // Default is to continue
}

Changed doFilter(..)
....
} catch (final TicketValidationException e) {
// ---------------- START NEW CODE ------------------
if (handleFailedValidation(request, response, e))
{
return ;
}
// ---------------- END NEW CODE ------------------

response.setStatus(HttpServletResponse.SC_FORBIDDEN);
log.warn(e, e);

if (this.exceptionOnValidationFailure) {
throw new ServletException(e);
}
}
....

Generally I don't think it is a good approach to patch CAS code.
Is it possible to get that or something similar into CAS Client?

This refers to CAS Client 3.1.3

Cheers,
Manfred

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

SingleSignOutFilter is not thread-safe

2008-07-08T23:27:29Z

SingleSignOutFilter uses a HashMapBackedSessionMappingStorage which internally
handles two HashMaps. Nothing is synchronized, but many concurrent threads can
cause get(), put() and remove() calls on these HashMaps.
For exampel this can cause NullPointerException if a HashMap grows in one thread
and another thread tries to get a particular entry of that HashMap.

An easy way to solve this would be creating a subclass of SingleSignOutFilter
and set another (i.e. thread-safe) SessionMappingStorage implementation
via setSessionMappingStorage() call in the init() method.
But due to the strict 'final' policy of CAS it is not possible to extend
SingleSignOutFilter.
So you end up writing your own SingleSignOutFilter.
Or might it by ok for the CAS developers to remove this 'final'?
Another option would be to make HashMapBackedSessionMappingStorage thread-safe.

This refers to CAS Client 3.1.3

Cheers,
Manfred

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: Migrating hacking CAS 2 behavior to login-webflow?

2008-07-07T17:17:27Z

Pat,

Scott is correct. All you need is "method=POST" and CAS will use HTTP POST to "redirect" to the service, in your case PeopleSoft. We got this working at Sac State.

Adam

Scott Battaglia wrote:

Pat,

We actually support POST its just something that hasn't been documented yet (Adam mentioned it to me once that it wasn't documented, and I said "yes, you're right, I should go do that" and then promptly forgot).

You just need to pass method=POST as part of the login url. (if I recall correctly).

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Mon, Jul 7, 2008 at 1:52 PM, Patrick Berry <pberry@...> wrote:

We have single sign-on to PeopleSoft. It's a total hack with a Java client and it's being replaced with a PeopleCode client (that we will share when we can). But...until such time I need to support the existing client. Now, I know that PeopleSoft will not accept auth via GET, only POST. We are running CAS 2 and we get it to work like so...

In the web.xml for CAS 2 we have this:

   <context-param>

   <param-name>edu.yale.its.tp.cas.serviceSuccess</param-name>

   <param-value>/goService.jsp</param-value>

   </context-param>

Then in goService.jsp we have this:

  if ((serviceId.indexOf("cmsweb.csuchico.edu") != -1) || (serviceId.indexOf("cmsdev.calstate.edu") != -1))

  {

   pageContext.forward("goServicePsft.jsp");

  }

Then in goServicePsft.jsp we something similar to the casPostResponseView.jsp which submits the ticket from a form that auto-submits on load.

Now, my question is should I be looking at the login-webflow.xml to get this same behavior in CAS3? I'm not entirely sure how to convince CAS that a service needs to get the ticket via POST.

Thanks,
Pat

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

[arybicki.vcf]

begin:vcard fn:Adam Rybicki n:Rybicki;Adam org:Unicon, Inc.;Professional Services adr:Suite 113;;3140 North Arizona Avenue;Chandler;AZ;85225;United States email;internet:arybicki@... tel;work:+1-480-558-2400 tel;home:+1-310-265-8286 tel;cell:+1-310-980-2758 x-mozilla-html:FALSE url:http://www.unicon.net/ version:2.1 end:vcard

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

smime.p7s (4K) Download Attachment

Re: Migrating hacking CAS 2 behavior to login-webflow?

2008-07-07T10:58:40Z

Pat,

We actually support POST its just something that hasn't been documented yet (Adam mentioned it to me once that it wasn't documented, and I said "yes, you're right, I should go do that" and then promptly forgot).

You just need to pass method=POST as part of the login url. (if I recall correctly).

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Mon, Jul 7, 2008 at 1:52 PM, Patrick Berry <pberry@...> wrote:

We have single sign-on to PeopleSoft. It's a total hack with a Java client and it's being replaced with a PeopleCode client (that we will share when we can). But...until such time I need to support the existing client. Now, I know that PeopleSoft will not accept auth via GET, only POST. We are running CAS 2 and we get it to work like so...

In the web.xml for CAS 2 we have this:

   <context-param>
   <param-name>edu.yale.its.tp.cas.serviceSuccess</param-name>

   <param-value>/goService.jsp</param-value>
   </context-param>

Then in goService.jsp we have this:
  if ((serviceId.indexOf("cmsweb.csuchico.edu") != -1) || (serviceId.indexOf("cmsdev.calstate.edu") != -1))

  {
   pageContext.forward("goServicePsft.jsp");

  }

Then in goServicePsft.jsp we something similar to the casPostResponseView.jsp which submits the ticket from a form that auto-submits on load.

Now, my question is should I be looking at the login-webflow.xml to get this same behavior in CAS3? I'm not entirely sure how to convince CAS that a service needs to get the ticket via POST.

Thanks,
Pat

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Migrating hacking CAS 2 behavior to login-webflow?

2008-07-07T10:52:45Z

We have single sign-on to PeopleSoft. It's a total hack with a Java client and it's being replaced with a PeopleCode client (that we will share when we can). But...until such time I need to support the existing client. Now, I know that PeopleSoft will not accept auth via GET, only POST. We are running CAS 2 and we get it to work like so...

In the web.xml for CAS 2 we have this:

<context-param>

<param-name>edu.yale.its.tp.cas.serviceSuccess</param-name>

<param-value>/goService.jsp</param-value>

</context-param>

Then in goService.jsp we have this:

if ((serviceId.indexOf("cmsweb.csuchico.edu") != -1) || (serviceId.indexOf("cmsdev.calstate.edu") != -1))

{

pageContext.forward("goServicePsft.jsp");

}

Then in goServicePsft.jsp we something similar to the casPostResponseView.jsp which submits the ticket from a form that auto-submits on load.

Now, my question is should I be looking at the login-webflow.xml to get this same behavior in CAS3? I'm not entirely sure how to convince CAS that a service needs to get the ticket via POST.

Thanks,
Pat

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Tests cas with JMeter

2008-07-03T08:07:23Z

Hello,

I must test my application with JMeter.

But, i have a problem with JMeter.

I can get the value of the lt parameter on the first request but
impossible to get the value of the ticket.

I create a 'Regular Expression Extractor' with the regular
expression : ticket=(ST-[0-9]+-.*)"

But the response is empty then no ticket.

I used the file finded in the cas svn, in the repository 'tests'.
Without modifications (except the ip address), the test failed.

Why ?

How do you do to pass the cas form ?

thanks,

Julien Redondo
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Sun $1M Open Source Innovation Grant

2008-07-02T17:47:39Z

Developers-

Please pass this link around to those who might be interested in a $1M Innovation Award Program sponsored by the Sun open source communities:

http://www.sun.com/software/opensource/awards/index.jsp

-Jonathan

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Re: Retrieve Principal Id in an ActionState

2008-07-02T08:24:24Z

Daniel,

The system is designed so that you're not supposed to be able to obtain a principal id until after a service ticket is validated (there are ways around it such as accessing the TicketRegistry directly, but those aren't recommended).

If your password expiration/change password tool needs access to the principal, it should be CASified. In theory you wouldn't want the change password application to do anything if it couldn't confirm the validity of the user anyway (i.e. passing principal as a parameter isn't really a good way of confirming the validity of the user).

However, it appears that this wouldn't work as you have specific requirements about TGTs and password expiration. If your resolvers don't make any changes to the NetID provided you could still always retrieve the original username provided from the Servlet Request. Its "unconfirmed" but if you're not using it for anything other than say pulling up a name then it shouldn't be a big deal.

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia

On Wed, Jul 2, 2008 at 11:14 AM, Daniel Almeida <daniel.almeida@...> wrote:

Hi,

I'm writing an ActionState to add to the CAS Webflow, which has to check
after the user authenticates correctly if his password is expired, is
expiring (in less than 30 days), or if it's OK.

We're using 3 different authentication handlers:

- An username/password authentication handler that queries our Kerberos
- X.509 Authentication Handler
- SPNEGO Authentication Handler

And use LDAP to resolve the Principal from the credentials.

When a password is expiring or has expired, we want to redirect the user
to a password change web page, passing as parameters the Principal Id
and the original service URL, so we can warn the user that his password
is expiring or that it has expired, and maintain the context (the
service where the user was authenticating).

This is mandatory, regardless of the authentication handler/method used,
and we only give a TGT after this check and only if the password is OK
or expiring in < 30 days.

The problem is that we can't "get" the principal Id in the ActionState
we're writing, that looks like:

public final class ISTChangePasswordWebpageAction extends AbstractAction {

private String istid;
private String serviceURL;

protected Event doExecute(RequestContext context) {

try{
final HttpServletResponse response =
WebUtils.getHttpServletResponse(context);
final WebApplicationService service = WebUtils.getService(context);

istid = ? // principal id independent from Authentication
Handler/method used

response.sendRedirect("https://changepasswordURL?"+ "url=" +
service.getId() + "&istid=" + istid);

}catch(Exception e){
...
}
return result("success");

}
}

Is there any simple way to retrieve the Principal Id in an ActionState?

Does anyone have a better approach to this problem? Preferably with no
changes to the cas-core?

Thanks in advance,
Daniel Almeida

Centro de Informática do Instituto Superior Técnico, Portugal
http://www.ist.utl.pt/
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

Retrieve Principal Id in an ActionState

2008-07-02T08:14:43Z

Hi,

I'm writing an ActionState to add to the CAS Webflow, which has to check
after the user authenticates correctly if his password is expired, is
expiring (in less than 30 days), or if it's OK.

We're using 3 different authentication handlers:

- An username/password authentication handler that queries our Kerberos
- X.509 Authentication Handler
- SPNEGO Authentication Handler

And use LDAP to resolve the Principal from the credentials.

When a password is expiring or has expired, we want to redirect the user
to a password change web page, passing as parameters the Principal Id
and the original service URL, so we can warn the user that his password
is expiring or that it has expired, and maintain the context (the
service where the user was authenticating).

This is mandatory, regardless of the authentication handler/method used,
and we only give a TGT after this check and only if the password is OK
or expiring in < 30 days.

The problem is that we can't "get" the principal Id in the ActionState
we're writing, that looks like:

public final class ISTChangePasswordWebpageAction extends AbstractAction {

private String istid;
private String serviceURL;

protected Event doExecute(RequestContext context) {

try{
final HttpServletResponse response =
WebUtils.getHttpServletResponse(context);
final WebApplicationService service = WebUtils.getService(context);

istid = ? // principal id independent from Authentication
Handler/method used

response.sendRedirect("https://changepasswordURL?"+ "url=" +
service.getId() + "&istid=" + istid);

}catch(Exception e){
...
}
return result("success");

}
}

Is there any simple way to retrieve the Principal Id in an ActionState?

Does anyone have a better approach to this problem? Preferably with no
changes to the cas-core?

Thanks in advance,
Daniel Almeida

Centro de Informática do Instituto Superior Técnico, Portugal
http://www.ist.utl.pt/
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

CAS-678 & Special Characters

2008-07-01T06:43:39Z

We don't have any non-English characters in any of our NetIds at Rutgers so I can't test this, but does anyone know of any problems with characters with accent marks, etc. with regards to CAS?

http://www.ja-sig.org/issues/browse/CAS-678

Usually it turns out to be a JVM issue and not a CAS issue but if anyone knows of any problems and they can help us diagnose that would be great!

-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev

CAS 3.2.2 Release Candidate 1

2008-06-26T08:21:58Z

Dear CAS Community,

We're happy to release the first release candidate for CAS 3.2.2. It contains a number of bug fixes and enhancements including:

Bug Fixes
* Fixed to the SAML response so it renders properly if a Principal has no attributes
* Fix for some classpath issues with Maven2 (note: there are some more when it comes to running tests that will be fixed in RC2)
* Meta data not updated when reauthenticating with a different userbase
* Services Management tool should ignore custom principals
* proxy-granting ticket invalidation by logout not working with JBossCache
* Multiple typos in German translation

Tasks
* Added a note clarifying that toStrings for credentials should be very careful about what they reveal.
* Upgrade to JBossCache 2
* Upgrade to Spring Security 2.0
* Add Log4J logging to JpaTicketRegistry
* Upgrade the Inspektr version to 0.7.0
* Upgrade to PersonDirectory 1.1.2
* web.xml and welcome page
* Upgrade to Spring 2.5.4

New Features
* RESTful API
* Slovenian language support
* Trusted LDAP module - transparent CAS authentication for trusted network clients

Enhancement:
* Add ability to transform user principal to lower or upper case for SPNEGO
* Remove stack trace from JAAS authentication failure

We're looking for everyone to test this as much as they can especially the upgrade to JBossCache 2! We're also looking for feedback on how people think they'll use the RESTful API. Right now its designed under the assumption that you'll really only collect one type of Credential with it, vs. the Login page which is designed to handle multiple types. Is the one-type design okay? Do people plan on handling multiple forms of credentials?

Also, while you're still reading this email (because you are, right? ;-)), just a reminder that we're still collecting feedback and ideas for the road map for CAS:
http://www.ja-sig.org/wiki/display/CAS/CAS+Vision+and+Roadmap

This is the easiest way to let us know what your needs are. If you don't tell us, we'll never know! (unless we have any mind readers on the team, which I'm unaware of)

You can download the RC release from the usual spot:
http://www.ja-sig.org/products/cas/downloads/

Thanks!
-Scott

-Scott Battaglia
PGP Public Key Id: 0x383733AA
LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________
cas-dev mailing list
cas-dev@...
http://tp.its.yale.edu/mailman/listinfo/cas-dev