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 list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
|
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:[EMAIL PROTECTED]
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
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________
Yale CAS mailing list
[email protected]
http://tp.its.yale.edu/mailman/listinfo/cas
