uP 2.6 CAS Integration JHU Dev Meeting Slot

Facilitator:
~awp9 is willing to facilitate this discussion, having prepared the background in UP-1650.

Schedule:
Tuesday April 24th, 9:35 am – 9:55 am , as part of the main uP dev meeting agenda. Timeboxed at 20 minutes. If more discussion required, let's use this timeslot as a launching point and then go from there.

Needs scheduled so that Scott Battaglia can remote in.

Rescheduled followup to Fri 4/27/07 2pm Eastern

Meeting needs to be rescheduled due to logistic and technical difficulties.

~awp9 suggests we skip the video conference bit and do a phone bridge instead, which he / Unicon can host. If shared desktop is actually valuable, ~awp9 can host that too, but needs advanced notice. Default will be phone bridge only.

Call in: (800) 981-8084
guest code 8861483

Confirmed participants:

Purpose / Outline / Content:

Address UP-1650, resolving code duplication between uPortal source tree and JA-SIG Java CAS Client uPortal support component.

(quick!) History outline describing how we got to where we are today
(quick!) Where we are today
(quick!) Shorcomings of the status quo
Options for addressing and decisions
- Where are the APIs CasConnectionContext and ICasSecurityContext going to live? uP source tree? jasig-java-cas-client source tree?
- What work to be done at code level. Who will do it?
- Documentation desperately needs help. how do we make it better how?
Potential for uPortal-CAS combined quickstarts

Why meet? What to discuss?

The very first and perhaps most important point of the meeting is to meet, to convene interested parties to discuss and achieve mindshare on goals, strategy, and tactics.

The topics for discussion at the meeting may best be understood in terms of the goal of the whole effort: make it easier and more easily understood how to CASify a uPortal.

Goals are probably the first thing to discuss. What are these APIs trying to accomplish? What is the goal of the JA-SIG Java CAS Client's uPortal integration subproject?

The meeting is to discuss which ICasSecurityContext APIs to standardize on, whether and which CasConnectionContext implementation to standardize on, and what to do about the various implementations – presumably make them implement whatever shared APIs are standardized on, but maybe to retire one or the other.

We could decide to keep the existing implementations where they are and improve them to share APIs.
We could decide that the JA-SIG Java CAS Client should provide the authoritative APIs and uPortal source tree should stop including these APIs. (I don't think this is a good idea – I think the APIs should be defined in the uPortal source tree since they feel "about uPortal")
We could decide that uPortal should ship with the APIs defined in its source tree but instead of including source code for implementing CAS security contexts, it should include the ja-sig Java CAS Client .jar and use those, retiring the defined-in-uPortal-source-tree-implementations.
We could decide that uPortal should ship not just with the APIs in its source tree but also the implementations there defined, and retire the uPortal portion of the JA-SIG Java CAS Client source tree, scoping that project back to just defining the general Java CAS Client piece. uPortal ships with the JA-SIG Java CAS Client .jar and includes the source code for integrating with it.

There are a plethora of options here. The meeting is to discuss their merits and arrive at a plan of attack.

Also to discuss documentation – what documentation will be updated by whom. Improving the code to follow a well-defined plan won't be as valuable if we don't make it clear to would-be consumers.

If we have time and aren't too exhausted, it could be worthwhile to discuss the prospects of embedding a CAS server instance in uPortal by default. That was discussed at the dev meeting and I think I'm starting to make inroads in people seeing this as not just a quickstart toy trick but a potential core feature of uPortal, to be using a CAS server under the hood.