It's been a few days, does anyone have questions we can answer or otherwise help move this along?
Thanks, Jason On 4/13/12 11:31 AM, Jason Dagit wrote: > Good questions. I solicited help from the team here in crafting a > response. > > On 4/12/12 5:24 PM, William G. Thompson, Jr. wrote: >> Hi Jason, >> >> Thanks for following up on this. Perhaps some dialogue will help us >> figure out the best path forward. Here are some questions and >> thoughts that come to mind. >> >> Is this code in production anywhere? Who is the main target audience >> of the account-linking feature? What other use-cases might be covered >> by this functionality that would be of interested to the Jasig >> community, to Higher Ed, to CAS adopters generally? What is the >> motivation for seeing this code included in the Jasig distribution vs >> keeping it as an extension in a Galois github repo? > > We have one trial deployment with the folks at SBGrid > (http://www.sbgrid.org/) and we are actively pursuing other deployment > opportunities. For example, we have one more trial deployment in the > works and we are working on an rpm based deployment so that our other > groups in grid computing can easily try it out at their sites. > > The target audience is really anyone who is trying to simplify their > identity system so that users can use one set of credentials but > access resources that may be using different credentials. In the grid > community this means that the attributes available to x509 credentials > and username/password credentials are linked. OpenID support could > also be added. Users are then able to supply their preferred > credentials and the account linking service takes care of fetching, > translating, merging, and presenting attributes (as appropriate) from > their linked credentials. > > The work we did on this project was funded by a grant from DoE. As > part of the proposal we promised to deliver an open source solution. > We believe integrating our CAS modifications back into CAS allows us > to keep that promise and it feels like the right solution to me at > least. It means that the account linking support in CAS is an official > part of CAS so that everyone can take advantage of it more easily. We > think this will lower the barriers to adoption. > > You might enjoy reading our whitepaper as it goes into more depth on > these topics. Please see the first link here in the documents section: > http://grid2.galois.com/ > > We are also merging changes we made to mod_auth_cas back into their > repository. > >> >> Did this feature require any modifications to core CAS code/apis, or >> did it more or less fit into the existing APIs? If merged into CAS >> distribution would it be easy for it to be turned off by default? >> Easy for folks to exclude it? > > I believe the code is completely additive although it depends heavily > on the internals of CAS in a few places. I would say it's off by > default and excluding it should also be easy. In our deployments we > use spring to control whether the account linking service is active. >> >> What are your thoughts regarding where this fits into the CAS roadmap >> based on the release strategy? >> https://wiki.jasig.org/display/CAS/CAS+Roadmap > I think we're in alignment with the proposed changes for CAS 4 and CAS > 5. Jonathan added the following: > As our changes are almost entirely additive (with the exception of our > tweaked ticket registry and some changes to the webflow XML), I'd say > our work is orthogonal enough to pretty much everything in their > release roadmap that it could happen any time. >> >> Are the normalized attributes returned in the CAS protocol payload? >> There has been a long and on-going discussion around rev'ing CAS >> Protocol doc to formally include attributes. This would normalize >> various ad-hoc methods and get the CAS clients to support it. I >> wonder how this fits in with that. > > Jonathan says: > The attributes are transmitted in a SAML XML payload using the > 'samlValidate' CAS API endpoint, and doing this did not require making > any changes to CAS. We did have to provide a tweaked ticket registry > to make this work, since the principal resolved by the user's > authentication is not the same as the principal that ends up > corresponding to the attributes transmitted to the RP (the former is > the third-party credential, possibly, and the latter is the 'local' > one). So the "ticket" issued by CAS needs to be munged so it > corresponds to the right principal when the RP asks for its > attributes. > > I don't think it matters *how* the attributes are transmitted; it > could be part of the CAS protocol payload itself or part of a separate > request as it is currently, but either way, for us, the special sauce > is in the logic that processes the attributes before they hit the > wire. > >> >> If this is more of a CAS3 plug-in like the OpenID work that Jerome >> did, then it might be possible to take a similar path if you are >> committed to maintaining this going forward, and able to comply with >> Jasig licensing requirements (apache2, CLAs, etc). - >> http://www.jasig.org/licensing > We are on board with apache2 licensing. Jonathan and I have already > filed contributor paperwork with jasig. Galois has a commitment to > seeing the account linking service gain adoption and as such we are > prepared to maintain this going forward. > > Thanks, > Jason > >> >> Best, >> Bill >> >> >> On Thu, Apr 12, 2012 at 7:07 PM, Jason Dagit<[email protected]> wrote: >>> We at Galois would really like to move forward with merging our CAS >>> additions into the mainline of CAS, in particular, the project >>> funding this >>> effort is about to end and Jonathan and I will move to other >>> projects. Once >>> that happens we can continue to do maintenance but our capacity for >>> this >>> work will be much smaller than it is currently. >>> >>> Earlier this year, I posted our CAS modifications on github >>> (https://github.com/dagit/grid2-als) and shared the link here. I >>> haven't >>> received any feedback on the code yet and we would really like to >>> keep this >>> moving. Galois can continue to do maintenance and the ideal time for >>> us to >>> work on this is now. >>> >>> What is the best way for us to move forward? The code is available on >>> github, but would a pull request against the CAS repository be more >>> helpful? >>> We haven't tried our code recently with the latest version of the CAS >>> source, so it's possible we need to do some work there. >>> >>> We are also wondering if the refactorings in CAS 4 will remove the >>> need for >>> some of the code we wrote to to be integrated directly into CAS. Could >>> someone who is experienced with the generalizations in CAS 4 help us >>> evaluate that? To help you understand how our modifications work, >>> here is a >>> link to our documentation: >>> http://grid2.galois.com/release-2012-01-28/cas-als-configuration.txt >>> >>> Questions? Comments? Concerns? >>> >>> Thanks, >>> Jason >>> >>> -- >>> You are currently subscribed to [email protected] as: >>> [email protected] >>> To unsubscribe, change settings or access archives, see >>> http://www.ja-sig.org/wiki/display/JSG/cas-dev > > _______________________________________________ > grid2 mailing list > [email protected] > http://lists.galois.com/mailman/listinfo/grid2 > -- > You are currently subscribed [email protected] > <mailto:[email protected]> as: [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-dev -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev
