Support CAS v3 protocol

[mmoayyed]

We need a new validator, Cas30 perhaps that is able to consume attributes and other protocol-related attrs. I do have a bit of time set aside this week to review this better and submit a PR.

[TheHokieCoder]

In order to fix this issue, #15 will also have to be fixed. Basically, as far as I can tell, the only differences in v2 and v3, as far as the client is concerned, are the extra attributes in the <cas:attributes> element and the new /p3/serviceValidate and /p3/proxyValidate endpoints (see CAS Protocol Specification). I have been working on a CAS v3 validator, so I will review the PR from the other issue and make a recommendation from there. Then the new endpoints will need to be implemented that force v3 validation. Full review of the spec and other, more fully-implemented, clients would be pertinent before merging any fixes.

[phantomtypist]

I was actually taking a look (cursory glance) at this one last week. I think you're right about #15 needing to be done as well. This one is not a simple/easy one :)

[TheHokieCoder]

@phantomtypist The PR from issue #15 is effectively merged into the feature branch I have for full support of CAS v3.0. I believe that we need to reject that PR, however, because it is hacking the CAS v2.0 service ticket validator to provide extra attributes in the CAS principal. While it is a common hack, it is not according to spec, and so I'd prefer to not implement in an official client library.

Also, I wanted to get a second pair of eyes on a curious section of code in the CAS v2.0 service ticket validator, found at Cas20ServiceTicketValidator.cs Line 141. I believe the throw statement inside the try block will be caught, causing the generic TicketValidationException to be thrown instead. To me, it would make sense to pull the inner exception out of the try block, put it after the catch block, so that if the failure response is successfully pulled out of the service response, a detailed exception could be thrown. The resultant code snippet would be:

AuthenticationFailure authFailureResponse;
try
{
    authFailureResponse = (AuthenticationFailure) serviceResponse.Item;
}
catch
{
    throw new TicketValidationException("CAS ticket could not be validated.");
}
throw new TicketValidationException(authFailureResponse.Message, authFailureResponse.Code);

Do you agree?

Finally, I am done with coding and testing the CAS v3.0 protocol support. Right now I'm just finishing up some commenting/housekeeping and then I'll be able to submit a PR. I only have a mock CAS server to test against (our university's CAS server doesn't support v3.0), so having someone else be able to test the new v3.0 protocol support would be helpful. I will have a PR for that here shortly.

[TheHokieCoder]

Also, should we make CAS v3.0 the default protocol for new installs (via the web.config.install.xdt file)? We obviously don't want to overwrite an existing config to switch to v3.0, but I don't see any harm in assuming v3.0 for new installs, letting the user bump back down to v2.0 if they want.

[HamidRezaAshkiyan]

Hi is there anyway to force app to use protocol 3? I have a problem in my project and i cant get attributes from the server.

[TheHokieCoder]

@HamidRezaAshkiyan Unfortunately this CAS client currently does not support the CAS version 3 protocol, as is evident by this issue to add support for the protocol to the project.

Furthermore, availability of developer support for this project has been extremely limited in recent months/years, so that is why development has essentially halted. Because of that, I cannot give you any fair estimate of if/when v3 support will be added. However, you may have some alternatives:

1. Look around to see if there are any other clients out there that support .NET Framework and CASv3
2. Check with your CAS server owners to see if there is another way you can get attributes (e.g. our institution also supports the SAML protocol, through which we get our attributes, since our server does not support CASv3)
3. Check out the fork/branch I had been working on for CASv3 support. I think that it was complete, but just needed extensive testing before merging into this project. It's been 13 months since I have touched that, so I can't make any guarantees that it will work and be free of bugs, nor that it will fully support everything in the v3 protocol. The easiest way to use it would be to remove the current NuGet package for this client and then reference the project for my fork/branch. That way, whenever you build your project, it would build and copy in the assemblies automatically.

Sorry that we don't have better news, but hopefully this will help you get moving in the right direction!

[HamidRezaAshkiyan]

Thanks. Is there any NuGet for your project? if is not how can I build one from it so i can reference it?

[TheHokieCoder]

@HamidRezaAshkiyan Unfortunately, no, there is no NuGet package for my fork of the project because I don't plan on releasing the client on my own. The plan is to implement CASv3 in my fork of the project, validate and test it, and then submit a PR to this original project.

I created issue #108 for us to further discuss what you are trying to do so that we don't add too much off-topic chatter in this issue. So please follow up with me in that issue instead.