Hi,

I'm definitely interested in contributing, I just wasn't sure of the
procedure.  My implementation differs significantly from what you have,
so my question was really one of whether you'd like to see a third
module in your library, replace the existing CasAuthenticationModule, or
just build a separate library.  I get that you don't want a fork in your
project, but please let me know whether you'd rather see this as a
separate HttpModule within your library or as a replacement for the
CasAuthenticationModule.

I've re-worked my implementation so that it won't require any API
changes to the existing code (just one config change).  However, while I
borrow a bit of code from the CasAuthenticationModule, it's definitely a
big departure from the approach in that module--it's essentially a new
implementation.  You can compare the two and decide whether or not this
is a replacement. 

I'll zip it up and attach it to a JIRA issue once I've done a little
more testing.

AbstractCasModule (existing)
+-- AbstractFormsAuthenticationCasModule (new)
    +-- FormsAuthenticationCasModule (new)

This module (I'm not attached to the name) introduces a couple of other
interfaces & classes to support the state.  This required adding a new
property to the CasClientConfiguration/web.config element.  The
formsAuthenticationStateProvider configuration element must be either
undefined or equal to 'CacheAuthenticationStateProvider'.  This would be
the basis of a pluggable storage mechanism (similar to how CAS1, CAS2,
and SAML ticket validators are pluggable).  I implemented the cache
based provider, but you could write your own provider for it.  

IFormsAuthenticationStateProvider (new)
+-- AbstractFormsAuthenticationStateProvider (new)
    +-- CacheAuthenticationStateProvider (new)
    +-- OracleAuthenticationStateProvider (hypothetical)
    ... 
    +-- MemcachedAuthenticationStateProvider (hypothetical)

The state provider enables client ticket verification (i.e., the server
must have the same ticket that you are presenting or else your ticket is
not trusted) and the following features exposed through
FormsCasAuthenticationModule's TicketManager property.  If you don't
define a formsAuthenticationStateProvider in the configuration, you
don't get any of the following bells and whistles.  If it is, you do.

FormsAuthenticationTicket GetTicket(string casTicket);
void InsertTicket(FormsAuthenticationTicket ticket, DateTime
expiration);
void UpdateTicketExpiration(FormsAuthenticationTicket ticket, DateTime
newExpiration);
bool RevokeTicket(FormsAuthenticationTicket ticket);
bool RevokeTicket(string casTicket);
bool ContainsTicket(FormsAuthenticationTicket ticket);
bool ContainsTicket(string casTicket);
void RevokeUserTickets(string netId);
IEnumerable<FormsAuthenticationTicket> GetAllTickets();
IEnumerable<FormsAuthenticationTicket> GetUserTickets(string netId);
IEnumerable<string> GetAllCasTickets();
IEnumerable<string> GetUserCasTickets(string netId);
IEnumerable<string> GetAllTicketedUsers();
bool VerifyClientTicket(FormsAuthenticationTicket clientTicket);

...also, SingleSignOut requires a formsAuthenticationStateProvider.
Without it, the SSO requests will be ignored.

Scott Holodak

-----Original Message-----
From: Marvin Addison [mailto:[email protected]] 
Sent: Monday, February 15, 2010 1:56 PM
To: [email protected]
Subject: Re: [cas-dev] DotNetCasClient

> I'm pretty sure Scott wasn't suggesting a fork, but rather simply
> inquiring how to best engage the community on some significant
> contributions.

"It's beginning to feel like either I should be copying code over to
another library"  -- sounds like a fork to me, but I'm glad to hear
you understand otherwise.

> I think you'll be pleased with the direction...
> I'd be happy to see Scott take up leadership of that piece if
> he's up to it.

I'm wholeheartedly in favor of recruiting more developers for this
project.  Speak up, Scott H, if you're interested in maintaining this
piece and I'll make arrangements for your commit access.

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


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