Hi Marvin,
I apologize ahead of time for the epic novel of a reply, but I'm really hopeful
to convince you and any interested parties to vote for the "Remove the
alternate module from the trunk and focus development efforts on the
Forms-based CasAuthenticationModule" option.
>> Mechanically, this is very different from the Java client
>> implementation and the existing .NET CAS client module implementations,
>> primarily due to the differences in how authentication is handled in ASP.NET
>> and the lifecycle of an application & request.
> I don't agree with that statement in general. While a comparison of
> components dedicated to integration with their respective frameworks,
> Forms Auth and the Java Servlets, would naturally show little if any
> similarity, the core operation of both the Java client and .NET client
> achieve many of the same operations with a similar design
> (Authenticator, Validators, Assertion). After all, they're doing much
> of the same things to integrate with CAS.
That's true. I guess I was referring to the mechanics from an integration
perspective. All three modules (current CasAuthenticationModule, previous
CasAuthenticationModule, CasAlternateAuthModule) follow the mechanics defined
in the protocol. Getting pieces like Gateway and Proxy authentication (inbound
and outbound) to work in a way that integrates well with the ASP.NET framework
required an architectural departure from the existing client codebase which,
coupled with the fact that I have been trying not to break the alternate
module, is why I've had to copy & paste code (evil).
> I will update and maintain CasAlternateAuthModule going forward if I
> determine it's valuable. The determining factor for me in whether this
> component has value is whether the CasAuthenticationModule configuration
> distills down to something trivial for folks that don't need the
> authorization and advanced security features of Forms auth.
The implementation and configuration will be drop-dead simple. It can be
installed on an application-basis or on a per-machine-basis
(%SYSTEMROOT%\Microsoft.NET\Framework\v2.0.50727\CONFIG\web.config). It
requires dropping the dll file in the Bin directory and editing web.config.
There is 1 custom config block, 1 HttpModule to install, some basic Forms
Authentication configuration (cookie timeout, path, cookie security, etc--the
majority of these are optional), and one or more authorization blocks to
control anonymous/authenticated resource access. This requires 0 lines of code
in your application outside of web.config. The features that are built on top
of the authentication (later in the request processing pipeline and in your
application's code) are all optional--if you don't need them, just don't
configure/use them:
- AuthorizeRequest - web.config
role providers, URL authorization, etc.
- ResolveRequestCache - web.config
user/role varied caching (all other cache varying works as usual)
- AcquireRequestState - web.config
session (generally cookie-based, not impacted by authentication)
- Code access security - application code
In ASP.NET, the authentication providers (Windows Authentication Provider and
Forms Authentication Provider) were designed to address 2 authentication
scenarios in a way that integrates with the request processing pipeline.
The Windows Authentication Provider model relies on IIS' built-in Digest,
Integrated authentication (NTLM or Kerberos), or Base64 encoded
implementations. IIS hands ASP.NET the credentials (thread executes in the
context of the Windows account) and ASP.NET sets the User property in the
AuthenticateRequest handler. It creates a WindowsIdentity and stores it in the
Principal. Because it's Windows-specific, it didn't make sense to implement
CAS around this module.
The Forms Authentication Provider model, together with the Membership Provider
Model, address the web UI-based authentication scenario with data-store
independence. CAS is essentially a web UI-based authentication provider with
data-store independence, it just doesn't live inside of the ASP.NET
application. The FormsAuthenticationModule implementation is sealed and isn't
flexible enough to support the advanced CAS features. It doesn't maintain any
server-side state regarding the FormsAuthenticationTickets outstanding, it just
relies on encryption of the FormsAuthenticationTicket inside of the
FormsAuthenticationCookie. This makes proxy authentication and externally
initiated single signout impossible. Implementing the CAS login behavior would
be possible with the FormsAuthenticationModule, but would require an additional
completely unnecessary redirection on the way out to CAS and again on the way
back from CAS (Page.aspx ->
Login.aspx?ReturnUrl=http%3A%2F%2Fwww.site.com%2FPage.aspx
->https://cas.server.com/cas/login?service=http%3A%2F%2FLogin.aspx[double-url-encoded-ReturnUrl]
-> Login.aspx?ReturnUrl=http%3A%2F%2Fwww.site.com%2FPage.aspx -> Page.aspx).
The FormsAuthenticationModule's SignOut implementation is sealed and can only
possibly affect the current application (can't initiate SingleSignOut)--it
essentially force-expires the FormsAuthenticationTicket in the
FormsAuthenticationCookie (to prevent cookie replay attacks).
This lack of flexibility is most likely the reason that MS decided to expose a
public API for FormsAuthentication behavior (cookie/ticket encryption and
decryption, validation, etc.). The approach with the CasAuthenticationModule
is to replace the behavior of the FormsAuthenticationModule with support for
the features in the CAS protocol. Because it deals in valid
FormsAuthenticationCookies and FormsAuthenticationTickets, the
FormsAuthenticationModule does not interfere with the CasAuthenticationModule
when the two modules are installed in an application at the same time (though
they don't need to be). Because of this, many of the ASP.NET login controls
are still completely functional. LoginView, LoginName, LoginStatus controls
all work as expected.
Also, server-side state management is opt-in with the CasAuthenticationModule.
If you want it to behave like the FormsAuthenticationModule and just trust
valid, non-expired FormsAuthenticationCookies and FormsAuthenticationTickets,
you just don't configure a TicketManager. This will frees up resources on the
server and improve performance (by a factor dependent on the type of data store
that is backing your TicketManager) at the expense of SingleSignout, pgtUrl
service validation/proxy ticket generation support, and administrative access
to view/revoke outstanding tickets and allow/restrict/observe multiple logins
per-user/per-IP/etc.
Removing the alternate module from the codebase will greatly simplify the
deployment & configuration experience from an implementer perspective. Plus,
it's not lost forever--we can branch or tag it in SVN. Implementers will not
have to worry about which module to install, which configuration options are
applicable to that module, and which ASP.NET features are usable with which
module. From a code maintenance and documentation perspective, it will make
CAS developers' jobs much simpler :-). The codebase will be smaller and more
manageable. Also, when the module hit's 1.0 status, the CasAuthentication
class will have a stable publicly accessible API to perform many CAS-related
tasks in code if they decide to do so. That API will be easier to unit test
than the comparable behaviors embedded in the HttpModules themselves.
Scott Holodak Aspire | A Plan for Princeton
Princeton University Office of Development
-----Original Message-----
From: Marvin Addison [mailto:marvin.addi...@gmail.com]
Sent: Friday, March 05, 2010 9:51 AM
To: cas-dev@lists.jasig.org
Subject: Re: [cas-dev] Feedback requested on dotnet-casclient
> - Remove the alternate module from the trunk and focus
> development efforts on the Forms-based CasAuthenticationModule
>
> - Have the CasAlternateAuthModule maintainers update their code
> to make use of the CasAuthentication static API implementation and actively
> sync with API changes.
My vote is for one of the above; I will update and maintain
CasAlternateAuthModule going forward if I determine it's valuable.
The determining factor for me in whether this component has value is
whether the CasAuthenticationModule configuration distills down to
something trivial for folks that don't need the authorization and
advanced security features of Forms auth. I expect I will find this
is the case and we can simply remove it and focus on
CasAuthenticationModule going forward.
M
--
You are currently subscribed to cas-dev@lists.jasig.org as:
sholo...@princeton.edu
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
--
You are currently subscribed to cas-dev@lists.jasig.org as:
arch...@mail-archive.com
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev
