.Net JasigCasClient

[Winfrey, Catherine]

Another issue that we probably need to consider is single sign out (which
I'll refer to as SSO here).  I am fairly new to CAS and my understanding of
this feature is based mostly on examining the Java client code.  It seems
like the same basic approach (storing sessions in a static Hashmap) would
work for our .Net client and we would use the session.Clear and
session.Abandon methods.

However, for the WFA implementation it is seems like the FAT associated with
the session being invalidated should also be removed from the client browser
(as in FormsAuthentication.Signoff per my reading).  Since SSO involves the
CAS server talking directly to the server hosting the CAS-protected .Net
application and not to this browser, I am not sure if the FAT associated
with the session being invalidated is available and even if it is how to
communicate with the browser to tell it to remove the FAT.

Thoughts?

Cathy

[Scott Holodak]

Hi Bill, Cathy,

I haven't really had a chance to dig into how CAS is implemented.  I haven't incorporated Single-signout in my application and I don't know what the CAS-Web server communication looks like.  I'll assume it's a regular HTTP request that gets handled specially from a trusted source.  If so, these can be handled by a Handler or Module (I forget which one is which).  I'll try and address the points conceptually, but correct me if I'm missing something.

===

Bill

My thinking is that you would want to encrypt the information necessary to recreate the Principal in the cookie.  When you authenticate the request, you attempt to decrypt the cookie.  If you can't, it means it was tampered with.  If you can, you recreate the principal with the decrypted data.  You don't literally need to serialize & de-serialize the principal.

If all that you're storing in the cookie is the username, you don't even have to re-invent the wheel.  Just use FormsAuthentication.SetAuthCookie(...).  The benefit here is that the .NET Framework takes care of validating the cookie & setting up the principal for requests when authenticating subsequent requests.

This is some code from my login handler:

[1] FormsAuthentication.SetAuthCookie(Username, false);
[2] FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket(Username, false, 30);
[3] FormsIdentity Identity = new FormsIdentity(Username);
[4] GenericPrincipal GenericPrincipal = new GenericPrincipal(Identity, null);
[5] HttpContext.Current.User = GenericPrincipal;
[6] System.Threading.Thread.CurrentPrincipal = GenericPrincipal;

In subsequent requests, the HttpContext.Current.User and System.Threading.Thread.CurrentPrincipal are set by the Forms Authentication module automatically and I don't have to worry about it.  The reason I had to do it in the Login event handler is because the cookie created in SetAuthCookie() isn't available until the next request and I need to do additional processing on the user prior to the login redirect.  If I didn't, the redirect would make lines [5] and [6] unnecessary.

See here for some more background: http://msdn.microsoft.com/en-us/library/ms998372(dev10ide).aspx

===

Cathy,

As far as single sign-off goes, my suggestion would be to add invalid tickets to the Cache object.  HttpContext.Current.Cache.Add(...). The Cache collection takes care of removing stale items.   I'm not sure how the Cache collection works across servers, but I'm pretty sure it's configurable like the Session provider.  On each request, check if the FormsAuthenticationCookie shows up in the Cache, and handle it accordingly.  

I'm not sure at what point in the request processing you'd handle single sign-outs.  My thinking would be BeginRequest (just before AuthenticateRequest).  I'm pretty sure that the Cache collection belongs to the Application, so it should be available.  You could destroy the cookie and clear out the principal.  That should be enough to get the Authorization subsystem to treat the request as anonymous.  Then the Authorization subsystem would take care of either redirecting you to the Login page or leaving you where you are (depending on the authorization rules for the page you're on).

Scott Holodak
REX | RIAS Extensions


----- Original Message -----
From: "William G. Thompson, Jr." <[hidden email]>
To: [hidden email]
Sent: Wednesday, May 6, 2009 12:10:19 PM GMT -05:00 US/Canada Eastern
Subject: Re: [cas-dev] .Net JasigCasClient

Hi Scott.  This issue is not so much as where to store the ticket as
to where to cache the ICasPrinciple and IAssertion.  In regular WFA
the username is just stored in the FAT and the IPrincipal is
re-created for every request.  Typically, CAS clients store the
CasPrincipal/Assertion in a server-memory cache (Session) that is tied
to a specific session.

Thoughts on where to store the ICasPrincipal/IAssertion?  I was
consider the Session and then adding another event handler to
store/retrieve it into Context.User, etc. for each request.

Bill

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Winfrey, Catherine]

I think the data needs to be more than just the username, it needs to be all
of the Assertion data received from CAS.  This data needs to be available for
display in the browser, etc.  One reason for not wanting to put this data in a
cookie (UserData field I assume) is the potential size of that data.

Also, I want to be sure I understand what you are proposing.  Are you saying
to include the information needed to recreate the Principal in the FAT cookie
itself or are you talking about a separate cookie?  I think we are talking
about the FAT cookie, but I want to be sure.

In terms of "In subsequent requests, the HttpContext.Current.User and
System.Threading.Thread.CurrentPrincipal are set by the Forms Authentication
module automatically", that's not what I've seen.  HttpContext.Currrent.User
is always null at the start of our event handler method.  Maybe I am not
understanding what you mean.

-----Original Message-----
From: Scott Holodak [mailto:[hidden email]]
Sent: Wednesday, May 06, 2009 14:05
To: [hidden email]
Subject: Re: [cas-dev] .Net JasigCasClient

Bill

My thinking is that you would want to encrypt the information necessary to
recreate the Principal in the cookie.  When you authenticate the request, you
attempt to decrypt the cookie.  If you can't, it means it was tampered with.
If you can, you recreate the principal with the decrypted data.  You don't
literally need to serialize & de-serialize the principal.

If all that you're storing in the cookie is the username, you don't even have
to re-invent the wheel.  Just use FormsAuthentication.SetAuthCookie(...).  The
benefit here is that the .NET Framework takes care of validating the cookie &
setting up the principal for requests when authenticating subsequent requests.

This is some code from my login handler:

[1] FormsAuthentication.SetAuthCookie(Username, false);
[2] FormsAuthenticationTicket Ticket = new FormsAuthenticationTicket(Username,
false, 30);
[3] FormsIdentity Identity = new FormsIdentity(Username);
[4] GenericPrincipal GenericPrincipal = new GenericPrincipal(Identity, null);
[5] HttpContext.Current.User = GenericPrincipal;
[6] System.Threading.Thread.CurrentPrincipal = GenericPrincipal;

In subsequent requests, the HttpContext.Current.User and
System.Threading.Thread.CurrentPrincipal are set by the Forms Authentication
module automatically and I don't have to worry about it.  The reason I had to
do it in the Login event handler is because the cookie created in
SetAuthCookie() isn't available until the next request and I need to do
additional processing on the user prior to the login redirect.  If I didn't,
the redirect would make lines [5] and [6] unnecessary.

See here for some more background:
http://msdn.microsoft.com/en-us/library/ms998372(dev10ide).aspx

===

[Koby Ram]

Hi,
I am looking for a .net client, there is a C# application I have and I would like to use CAS as my authentication method, any feedback will help ,thanks

Koby.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Winfrey, Catherine]

I am helping to develop a .Net Client written in C#.  It is currently in the
JaSig sandbox (https://www.ja-sig.org/svn/sandbox/JasigCasClient/trunk).  It
includes most features, including Saml 1.1 support.

-----Original Message-----
From: Koby Ram [mailto:[hidden email]]
Sent: Tuesday, June 23, 2009 01:25
To: [hidden email]
Subject: [cas-dev] .Net Client

Hi,
I am looking for a .net client, there is a C# application I have and I would
like to use CAS as my authentication method, any feedback will help ,thanks

Koby.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev

[Koby Ram]

Thanks.

Thanks to cwinfrey for the great coding.

I have a desktop application using .NET Win Forms can anyone think of a way to do it? I need the user to authenticate with the CAS server and upon successful one we will be given the menus, any help will do.

Thanks
Koby.

-----Original Message-----
From: Winfrey, Catherine [mailto:[hidden email]]
Sent: Tuesday, June 23, 2009 3:53 PM
To: [hidden email]
Subject: RE: [cas-dev] .Net Client

I am helping to develop a .Net Client written in C#.  It is currently in the
JaSig sandbox (https://www.ja-sig.org/svn/sandbox/JasigCasClient/trunk).  It
includes most features, including Saml 1.1 support.

-----Original Message-----
From: Koby Ram [mailto:[hidden email]]
Sent: Tuesday, June 23, 2009 01:25
To: [hidden email]
Subject: [cas-dev] .Net Client

Hi,
I am looking for a .net client, there is a C# application I have and I would
like to use CAS as my authentication method, any feedback will help ,thanks

Koby.

--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see
http://www.ja-sig.org/wiki/display/JSG/cas-dev


--
You are currently subscribed to [hidden email] as: [hidden email]
To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-dev