uP 2.6 CAS Integration JHU Dev Meeting Slot

Facilitator:
Andrew Petro 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.

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

Needs scheduled so that Scott Battaglia can remote in.

Decisions and Action Items

Decision: Standardize on in-uPortal-codebase APIs for CAS security providers and CAS connection context.
Action Item: Andrew Petro will place a uPortal 2.5.3 GA .jar in the Maven2 repo so that JA-SIG Java CAS Client can compile against it. DONE pending review.
Action Item: ScottS will adjust JA-SIG Java CAS Client for a 3.0.1 release to implement these APIs.
Decision: Stick with existing default config and .jar dependencies shipping with 2.6
Action Item: Andrew Petro Identify documentation to be updated to reflect 2.6 default way of CASifying, in a Jira issue REQUESTED update via Jira issue
Decision: Revisit making JA-SIG Java CAS client integration the default commented-out-but-shipping-with-uP approach for a post-2.6.0 release, ideally after someone has used it in production, and after doco for how to do it now that the APIs conform is better baked.
Decision: Pick up discussion of potential of embedding CAS in uPortal @ Denver conference in a uP 2.7 BOF slot
Action Item: NEEDS OWNER will propose the 2.7 BoF conference slot

Meeting background

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.