TLDR: .NET CAS client needs to catch up to the times

There are some pretty big changes taking place in the .NET space recently
that relate to the CAS client. Previously, ASP.NET and IIS were
inseparable.  Recently, things have begin shifting towards OWIN (Open Web
Interface for .NET - www.owin.org).  Architecturally, this is practically a
reboot for the bottom layer of the ASP.NET stack and a lot of the things
that the existing CAS client depends on are either not there in their
current form (HttpModules) or have been reimagined (Memebership -->
Identity).  There are some other changes going on elsewhere in .NET that
relate to the CAS client.  Big pieces of Windows Identitiy Foundation have
made their way into the core .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 CAS client won't necessarily be broken on the new stack, but users will
be stuck with a dependency on IIS as the rest of the .NET world breaks free
of this.  More significantly, 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.  The Forms Authentication module now natively
returns ClaimsPrincipals.  By not following that convention, we're somewhat
broken in >= .NET 4.0 for applications that need to be security/claims
aware.  The 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.

It's going to be impossible to move the client forward without abandoning
.NET 3.5 SP1 (2008) and earlier versions of the framework.  Even compiler
directives won't help here.  I've been experimenting with ways to get the
existing client plugged into either the System.Web or OWIN stacks, but it
is a major refactor and it's going to require 4.0 at a minimum.  Both
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 just wanted to get this out there so it's on the other dev's radar and
get a conversation going.  I've been working with OWIN for about a year,
but roughly half that time it has been pre-release.  I'm definitely not an
expert on this stuff yet, but I should be able to answer or at least track
down answers.

-Scott

-- 
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

Reply via email to