First, I sincerely appreciate your taking the time to share your perspective and expertise.
> TLDR: .NET CAS client needs to catch up to the times I'm not at all surprised. > Big pieces of Windows Identitiy Foundation have made their way into the core Makes sense. > .NET Framework and the languages now offer proper support for asynchronous > operations which we should be leveraging for things like ticket validation > and proxy ticket requests. The same is true for the Java space, but I just don't see the value of async for the .NET client in terms of performance. If async is required to support modern application design, then that's another matter. You'd probably have to describe more about application architecture to make it sensible to me. I know that in the Java space, moving to async requires abandoning the assumption of a single, immutable thread for the entire request lifecycle. That's a fundamental design assumption that goes deep into most webapps, and breaking it means risking defects. If that's the cost we would incur here, then it seems a hard case to make. > the existing client won't interact properly > with a lot of security-related libraries in recent .NET versions as we are > using our own IPrincipal implementation rather than leveraging the new > ClaimsPrincipal class. That sounds like an important point of functionality that should be addressed as soon as possible. We're relying more and more on the .NET client at Virginia Tech and I would like it to have all the capabilities needed to provide seamless integration for arbitrary ASP.NET webapps. I believe we've met that requirement for the most part to date, but you make a compelling case that the environment has changed and it's time to adapt. > ClaimsPrincipal class solves a lot of problems for us. Particularly, it > gives us a proper place to store attributes released during ticket > validation and to persist/retrieve them between requests. It gives us a > nicer story for role-based authorization. All that sound positive once we get past the initial bump of what sounds like some pretty significant reorganization of source. > it is a major refactor and it's going to require 4.0 at a minimum. Sounds like there's a good case for going 4.0+. We might want to poll the community before we decide on a particular target version; feedback might even suggest we could safely target something even more recent. > implementations share some code, but have separate dll's depending on which > stack you're trying to plug into. This basically means splitting our > existing library into 3 dll's/nuget packages (Core, System.Web, OWIN). I recall that we leveraged your insight and expertise to fix some fairly problematic design issues early on in the project. In any case I trust your judgement here and I imagine we would rubber-stamp your design. > I'm definitely not an > expert on this stuff yet, but I should be able to answer or at least track > down answers. You're the closest we have to a .NET expert and I assume you would lead the effort to make the changes you described. That's not to say you couldn't delegate some tasks, but the module organization and design is yours. In addition, it might be a good time to attempt to recruit more .NET developers to the project; that might allow you to delegate more broadly. M -- 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
