Is this project still supported?

[hn3000]

Sorry, no offense intended, but is this project still supported?

Or is there a better solution for using CAS and .net together?

[phantomtypist]

Are you looking for a .NET Core variant or is there something else missing that you'd like to see?

---

From: hn3000 notifications@github.com Sent: Friday, March 29, 2019 6:33:56 AM To: apereo/dotnet-cas-client Cc: Subscribed Subject: [apereo/dotnet-cas-client] Is this project still supported? (#91)

Sorry, no offense intended, but is this project still supported?

Or is there a better solution for using CAS and .net together?

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHubhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fapereo%2Fdotnet-cas-client%2Fissues%2F91&data=02%7C01%7C%7Cbd0077e2e5a3441860ae08d6b4320ca2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636894524377327100&sdata=7Jov71DT7ZyvsT7SrEhQ62QE7%2B6xdWozVRAUVnB8xoQ%3D&reserved=0, or mute the threadhttps://eur03.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgithub.com%2Fnotifications%2Funsubscribe-auth%2FABtFsIULeYpDc3TkKbFR-DomnJ96Z8AVks5vbewUgaJpZM4cSGI-&data=02%7C01%7C%7Cbd0077e2e5a3441860ae08d6b4320ca2%7C84df9e7fe9f640afb435aaaaaaaaaaaa%7C1%7C0%7C636894524377337111&sdata=UiuXR739dnhUoTcZ7kVt03PqAVRAPZCc%2BpJlz4pKUdA%3D&reserved=0.

[hn3000]

No, .NET Core is not an issue for me, but I'm concerned about #64, #76, #79 -- especially #64 is already two years old and seems rather serious.

The relevant class has this commented code (and directly after that you'll find the hardcoded things mentioned in #64):

https://github.com/apereo/dotnet-cas-client/blob/84967a4bc9b6dcd0308146fc63e25085e5347024/DotNetCasClient/Validation/TicketValidator/Saml11TicketValidator.cs#L135-L184

And the fix has been planned for release 1.2 since 2017 -- which made me wonder.

Is there anything that I could do to help with this?

[hn3000]

Oh, just realized, it's #89 that would interest me, not #79 .

[phantomtypist]

There really isn't anything to be concerned about with #64 because it's basically for logging purposes. There is no imminent security concern. Reference: https://github.com/apereo/cas/blob/2175a0c6e7a62bdbf182979a2c6f875c6e6d655a/docs/cas-server-documentation/protocol/CAS-Protocol-Specification.md#423-saml-request-values

For it to be beneficial you'd have to have detailed request/response logging configured on both your CAS web server and the web server your application runs under so that way you could correlate the requests and responses between the two servers.

I honestly didn't feel like it was high priority because nobody ever complained about it and said they needed it fixed for logging purposes as far as I could tell for the last 9 years. I deemed it ultra-low priority and backburnered it. I know that seems like a piss poor excuse, but it doesn't mean it shouldn't be fixed.

I'll change it tonight and get a release out over the weekend that fixes #64.

As far as me MIA goes, I've been adding hoomans to the planet and working a full time job. That's what's been consuming my time since my last commit. Things have started to ease up so I should be able to commit more time to several projects that need TLC. If someone wants to come over and watch my litter of kids so I can code that works for me :)

Next up for the the suite of .NET CAS repos is to 1) get unit testing scaffolded at a minimal level so other people can contribute unit tests if they have time and then 2) fully implement some of the distributed ticket caching add-ins. 3) After that I'll worry about adding .NET Core and OWIN support. There are already two other projects that accomplish .NET Core and OWIN very well and I'll likely just ask those maintainers kindly if they wouldn't mind folding their code into this project under the Apereo org.

As for #79 and #89, they are both very special circumstances. #89 requires nothing from us, but 100% custom code in your application(s). I want to avoid adding too many custom features in the project that only a small minority would use. Like I said in one of my comments in issue #89 the easiest way to implement this would be to stand up an IdentityServer v4 and have your application authenticate with that and in turn IdentityServer could serve up multiple authentication methods, including CAS. Like the last commenter said, there is no documentation from IdentityServer on how to integrate CAS, but IMHO if you use v4 it's ASP.NET using the .NET Framework and if you already code ASP.NET and C# you should be able to work your magic and implement it on your own... the documentation is there for other providers, just not CAS... so follow that documentation, but swap out for CAS. If you didn't want to do the IdentityServer you'd have to roll our own custom AuthenticationAttribute with both your custom login and CAS logic all in there. That's something we can't do from within our project nor would I want to venture down that rabbit hole. I should probably close out that issue.

As for #79 that's a way custom problem and I honestly think the person is trying to solve the wrong problem. That person should really just configure the CAS server at the URL they wanted and customize that page to look how they want. And then in the ASP.NET web.config they'd just plug that URL into the URL fields required by the .NET CAS client. I should probably just close that issue as well.

Lastly, as for #76, the OP never got back to me with respect to my question (https://github.com/apereo/dotnet-cas-client/issues/76#issuecomment-369122140) A lot of the time the logout feature will not work if your CAS server is not configured correctly. Usually the people that set up the CAS server is a different team of people than the programmers making the application... and sometimes they don't discuss these things. I'm going to guess since the OP never got back to me (he/she did respond several times, but not after that last message I linked to) that what I said somehow solved his problem. It's working fine in my environment, so without a reproduction scenario along with all the configurations/code in your app and also the CAS server it is very hard to identify what could be going wrong.

Besides #64, if there are other issues that you think you'd like take a wack at be my guest and do the coding and submit a PR. Just read over the readme (especially this part: https://github.com/apereo/dotnet-cas-client/issues/76#issuecomment-369122140) and make sure the project builds via the Cake script okay before submitting your PR.

GitHub

apereo/cas

Apereo CAS - Enterprise Single Sign On for all earthlings and beyond. - apereo/cas

[hn3000]

Thanks a lot for that comprehensive answer!

Congrats re: adding hoomans, that's hard work.

I also wasn't aware that this library is not part of apereo's commercial endeavour ... so thanks again for taking time to respond!

About #64 -- the importance of the request id was not clear, but the ability to debug and correlate log output would be very relevant for me.

89 -- my reading was that the library was actively in the way of creating .net sessions any other way, I think it should at least offer an escape hatch to tell it to just ignore the session if it doesn't fit it's own model. If there is that would be enough for me. Standing up a separate server for this purpose seems somewhat excessive. I might have a stab at proposing a solution if it really becomes a problem for me.

79 -- fully agreed, that seems a weird problem to bother you about.

76 -- well, I trust your experience and layer 8 problems seem to abound in this problem space ...

Again, not trying to tell you your job, but maybe commenting and closing them would be the best solution?

Also, please feel free to close this issue -- or tell me to do it.

Cheers!

[phantomtypist]

@hn3000 I really had thought I put a contributing.md file in the repo, but I guess I forgot to do that. Until I do that this is the gist:

If you want to contribute a PR I am totally on board with that, however I would first open an issue and talk about what you are planning to do. This way we can have a placeholder for a discussion around what you are going to do. I feel like it will prepare you and I better than just coding in the dark and poof a PR appears. Just my two cents though.

Next, you'll want to fork your repo, but work off of the DEVELOP branch. I am following the GitFlow methodology in this specific repo. When you submit the PR make sure it's based against our DEVELOP branch. If you forget that part I'll just change it to point to said branch. The AppVeyor build server will build your PR at that point in time using the Cake build script in the repo.

Yeah, for #76 and #79 there are just a lot of moving parts and sometimes developers and sysadmins just don't communicate with each other all that well. Same reason for #86 probably. ¯_(ツ)_/¯

As for going about working on #89, sure, take a stab at it!

[phantomtypist]

@hn3000 we also have Gitter chat rooms if you want to discuss things there adhoc. The main room (includes Java too) is a bit more active ;)

https://gitter.im/apereo/home

apereo/home - Gitter