The documentation there so far looks like a good start. We'll wait to hear back from UCB about the license before making too much headway ;-)
On Wed, Apr 2, 2008 at 3:32 PM, Adam Rybicki <[EMAIL PROTECTED]> wrote: > Scott, > > Sounds like a good plan. I've started on #1. Look here: > http://www.ja-sig.org/wiki/x/5wPI. > > OK, so I can't write this fast--I copy/pasted this documentation from the > original documentation delivered to UC Berkeley. I will make another pass > through it to clarify some terminology that was obvious to UCB and Unicon in > the course of the project, but would be confusing to everyone else. > > I have started on #2 and I will follow up with UCB tomorrow. > > As for #3, it sounds like a good approach and we'll wait for UCB to tell > us about the license. > > Adam > > Scott Battaglia wrote: > > Adam, > > This looks like an interesting contribution and I'm glad that UCB is > considering contributing it! We should do a couple of things: > > 1. Post any documentation into the CAS User Manual (clearly marking it as > a feature under consideration for let's say the 3.2.2 release) > 2. Work with UCB, Unicon, and JASIG to ensure all the fun legal license > compliance stuff ;-) > 3. Figure out the best place to put the code. A good first step > (depending on the UCB license) may be to create a JIRA issue and attach the > source. Depending on what's required, amount of support needed, your > availability for enhancements, etc. this may just get contributed or you may > be offered commit access to the module in the cas3 source (at this point > anything is up in the air). > > Thanks! > -Scott > > On Tue, Apr 1, 2008 at 8:26 PM, Adam Rybicki <[EMAIL PROTECTED]> wrote: > > > While working with the University of California, Berkeley (UCB), Unicon > > implemented what UCB refers to as "Second-level CAS." The idea is that this > > server controls authentication to "highly secure" or "restricted" Web > > applications. These applications are CAS-enabled and use the Second-level > > CAS for their authentication. However, Second-level CAS is itself > > CAS-enabled, and in order to get to it, the user must first authenticate to > > the Primary CAS server. Obviously, Second-level CAS uses different type of > > credential (alphanumeric PIN one-way-hash-encoded and stored in LDAP) than > > Primary CAS (Kerberos). Additionally, Second-level CAS accepts and > > processes Single Sign-Out callbacks from Primary CAS and invalidates its TGT > > that was associated with the ST represented by the Primary CAS ST. > > > > So, this is pretty neat and UCB wishes to share this solution with the > > JA-SIG community. Before this gets packaged into some "contrib" package, I > > would like to document this solution on the JA-SIG Confluence. Can someone > > suggest the most appropriate place for this documentation? > > > > Thanks, > > Adam > > > > _______________________________________________ > > Yale CAS mailing list > > [email protected] > > http://tp.its.yale.edu/mailman/listinfo/cas > > > > > > > -- > -Scott Battaglia > PGP Public Key Id: 0x383733AA > LinkedIn: http://www.linkedin.com/in/scottbattaglia > > ------------------------------ > > _______________________________________________ > Yale CAS mailing [EMAIL PROTECTED]://tp.its.yale.edu/mailman/listinfo/cas > > > _______________________________________________ > Yale CAS mailing list > [email protected] > http://tp.its.yale.edu/mailman/listinfo/cas > > -- -Scott Battaglia PGP Public Key Id: 0x383733AA LinkedIn: http://www.linkedin.com/in/scottbattaglia
_______________________________________________ Yale CAS mailing list [email protected] http://tp.its.yale.edu/mailman/listinfo/cas
