Was in mmc adding the snap-in's when I got your email ... thanks!!

Now to integrate to our app ...

Cheers,
jason
________________________________________
From: Scott M. Holodak [[email protected]]
Sent: Wednesday, September 15, 2010 3:28 PM
To: [email protected]
Subject: RE: [cas-dev] .Net CAS Client (w/MVC 2)

Hi Jason,

I'm pretty sure you're right to put it in the Trusted Root Certification
Authorities store, just make sure you add it for the computer account,
not your account (i.e., via mmc.exe, not certmgr.exe).

Click Start/Run and type mmc.exe.  Click File, Add/Remove Snap-In.  Add
the Certificates option and select the Computer account, Local Computer,
OK, OK.  Expand the Certificates and the Trusted Root Certificate
Authorities node.  If your CA cert isn't there, there's your problem.
Right click on the Certificates node (or in a blank spot in the right
pane), and hit All Tasks > Import and browse to your CA certificate.

If all else fails, here are a few more things to check:
- Browse to your CAS server in IE again, right click somewhere and hit
properties.  Click the Certificates button and make sure that it shows
both the CA cert and the CAS server's cert in the certificate chain.  If
you only see the CAS server's SSL cert in the chain and IE still says
everything is ok, you might have mistakenly added the CAS server's SSL
cert as trusted rather than the CA cert that issued it.
- Double check that your client is configured to connect to
yourcasserver.umd.edu and not just yourcasserver.

-Scott

> -----Original Message-----
> From: Jason Edward White [mailto:[email protected]]
> Sent: Wednesday, September 15, 2010 1:13 PM
> To: [email protected]
> Subject: RE: [cas-dev] .Net CAS Client (w/MVC 2)
>
> I'm pretty sure I  have an SSL Trust issue since my additional debug
> generates this ...
>
> 2010-09-15 12:37:45,887 [5] ERROR AbstractUrlTicketValidator -
> Exception Thrown: System :
> System.Security.Authentication.AuthenticationException: The remote
> certificate is invalid according to the validation procedure.
> ....
>    at System.Net.ConnectStream.WriteHeaders(Boolean async) : The
> underlying connection was closed: Could not establish trust
> relationship for the SSL/TLS secure channel.
> Googling the last line there comes up with the workaround you
> suggested.
>
> So, it's obviously a chain of trust issue and my lack of how certs
work
> with windows and .Net.  I am running my own CA in the development
> environment. I have generated both certs (webapp and cas) against a
> self-generated root cert. I have imported that root cert on the webapp
> machine in the 'Trusted Root Certification Authorities'. If I browse
to
> the cas server, it is validated and IE says it is OK (no need for
extra
> import or extra click-through to say I trust). So, it would appear
that
> .net is not using/respecting that root cert.  So ... close ...
>
> Thanks for all the help so far.
>
> Jason
> ________________________________________
> From: Scott M. Holodak [[email protected]]
> Sent: Tuesday, September 14, 2010 2:47 PM
> To: [email protected]
> Subject: RE: [cas-dev] .Net CAS Client (w/MVC 2)
>
> Hi,
>
> On the Example WebSite, make sure you have a 'logs' directory.  In
> Explorer, grant 'Everyone' full permission to it.  Then re-attempt.
> The
> client should produce a DotNetCasClient.log4net.log file in that
> directory which should have more info.
>
> Do some sanity checks on the app server & CAS servers' SSL
> certificates.
> Make sure the host names are correct & fully qualified and that you
are
> redirecting to fully qualified domain names.  Also make sure neither
> side's certificate has expired.  Check out the chain on both
> certificates.  If they are both self-signed, you've probably got some
> certificate trust issues to resolve.  Without proxy support, it's
> likely
> going to be an issue of the client (Example web site) not trusting the
> SSL certificate of the CAS server.
>
> I would try the
ServicePointManager.ServerCertificateValidationCallback
> workaround at least temporarily.  If it works, you can be 100% certain
> you have an SSL trust issue to resolve.
>
> -Scott
>
> > -----Original Message-----
> > From: Jason Edward White [mailto:[email protected]]
> > Sent: Tuesday, September 14, 2010 2:36 PM
> > To: [email protected]
> > Subject: RE: [cas-dev] .Net CAS Client (w/MVC 2)
> >
> > OK ... so we've resurrected (rebuilt) our dev. server and I'm back
to
> > working on this ...
> >
> > As I understand it, turning the poxy support off is a matter of
> > removing the proxyTicketManager in the web.config (which I did ...
> > commented it out). Same result. I think I came across (previously)
> the
> > the hack which you mention, and I'm not that desperate yet (and
> > probably won't ever be ... kind of self-defeating).
> >
> > Again ... CAS server is validating (see log snippet below) and
> issuing
> > tickets. Local .net app (using example web site as test case before
I
> > try to implement on my own app) is just not accepting and issuing
the
> > cookie.  Back to tracing through it, but if there are any other
> > insights, they would be greatly appreciated.
> >
> > 2010-09-14 14:24:37,539 INFO
> > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service
> > ticket [ST-72-9MCSH7koVWZUp1O3UAcc-cas] for service [https://cas-
> > eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user
> > [jwhite]>
> > 2010-09-14 14:24:37,676 INFO
> > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service
> > ticket [ST-73-yCMVlH7jkoZR6cFxmmfn-cas] for service [https://cas-
> > eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user
> > [jwhite]>
> > 2010-09-14 14:24:37,729 INFO
> > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service
> > ticket [ST-74-MkkiXoJF70eh7ZUIugko-cas] for service [https://cas-
> > eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user
> > [jwhite]>
> > 2010-09-14 14:24:37,784 INFO
> > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service
> > ticket [ST-75-BHA59n22lFSoscu4eoK7-cas] for service [https://cas-
> > eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user
> > [jwhite]>
> > 2010-09-14 14:24:37,842 INFO
> > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service
> > ticket [ST-76-wNzhLgacTifduzQqXAey-cas] for service [https://cas-
> > eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user
> > [jwhite]>
> > 2010-09-14 14:24:37,949 INFO
> > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service
> > ticket [ST-77-cF3JTAmouVeKNtxwismv-cas] for service [https://cas-
> > eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user
> > [jwhite]>
> > 2010-09-14 14:24:38,010 INFO
> > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted service
> > ticket [ST-78-QUCx5Fi7bIfGjOxMUSrb-cas] for service [https://cas-
> > eg.server:8443/Restricted/UsersRoleOnly/default.aspx] for user
> > [jwhite]>
> >
> > TIA,
> > Jason
> >
> > ________________________________________
> > From: Scott M. Holodak [[email protected]]
> > Sent: Wednesday, September 01, 2010 5:02 PM
> > To: [email protected]
> > Subject: RE: [cas-dev] .Net CAS Client (w/MVC 2)
> >
> > Hi,
> >
> > Your app server needs to trust the certificate chain of your CAS
> > server.
> > Google ServicePointManager.ServerCertificateValidationCallback for a
> > potentially dangerous hack to get around this.
> >
> > Also if you have proxy support turned on, your CAS server needs to
> > trust
> > the development certificate that you created for you web app.  To
get
> > around this, try turning the proxy feature off in the client.  You
> > won't
> > be able to generate (and validate? Not sure) proxy tickets.  Then it
> > will use serviceValidate instead of proxyValidate and it should
> bypass
> > SSL problems between from the CAS server to your app server.
> >
> > -ScottH
> >
> > > -----Original Message-----
> > > From: Jason Edward White [mailto:[email protected]]
> > > Sent: Wednesday, September 01, 2010 4:18 PM
> > > To: [email protected]
> > > Subject: RE:[cas-dev] .Net CAS Client (w/MVC 2)
> > >
> > > Scott Holodak and I  have been back and forth a little on this
> > > privately. decided to join and bring this to the list.
> > >
> > > I'm having an issue with CAS authentication with the .net cas
> client
> > > when deployed on the server. It seems to run fine from Visual
> Studio,
> > > but not from the server. I'm using the example site as my baseline
> to
> > > get comfortable with the .Net CAS Client for MVC, then I plan to
> port
> > > it to our app.
> > >
> > > In the try/catch for CasAuthentication.cs >>
> ProcessTicketValidation
> > I
> > > added
> > >
> > > Log.DebugFormat("******** ProcessTicketValiation -
> > > TicketValidationException {0}; {1}; {2}  ************", t.Message,
> > > t.InnerException, t.Source);
> > > ... to the catch block.
> > >
> > > This is the result:
> > > 2010-08-27 16:39:22,140 [7] DEBUG CasAuthentication - ********
> > > ProcessTicketValiation - TicketValidationException CAS server
> ticket
> > > validation threw an Exception; System.Net.WebException: The
> > underlying
> > > connection was closed: Could not establish trust relationship for
> the
> > > SSL/TLS secure channel. --->
> > > System.Security.Authentication.AuthenticationException: The remote
> > > certificate is invalid according to the validation procedure.
> > >
> > > Since the difference is my local box to the server, I imagined it
> was
> > a
> > > cert issue.
> > >
> > > Important to note ... I have created a CA in the development
> > > environment and have imported the root signing cert on my desktop
> and
> > > on the servers (using keytool on the linux/CAS box and with the
> cert.
> > > install utility on windows).  So, it should not be an issue of the
> > > trust/chain as far as I can see. We rebooted it for good measure,
> but
> > > it's taking FOREVER to reboot. While I wait to see what's up with
> > that
> > > (and potentially rebuild my development server) ... Any
> > insights/ideas?
> > >
> > > TIA!
> > >
> > > Jason
> > >
> > > ________________________________________
> > > From: Jason Edward White
> > > Sent: Friday, August 27, 2010 4:02 PM
> > > To: Scott M. Holodak
> > > Subject: RE: .Net CAS Client (w/MVC 2)
> > >
> > > Sorry on one count ... the app server should have been:
> > > https://cas-eg.foo.umd.edu
> > > ... and the cas server:
> > > https://sso-dev.foo.umd.edu
> > >
> > > Sorry ... habit of obfuscating log posts in email, lists, forums
> etc.
> > I
> > > mangled that one.  Am working the SSL/Trust angle now. that is
what
> > the
> > > innerException is telling me it is.
> > >
> > > Thanks,
> > > Jason
> > > ________________________________________
> > > From: Scott M. Holodak [[email protected]]
> > > Sent: Friday, August 27, 2010 3:05 PM
> > > To: Jason Edward White
> > > Subject: RE: .Net CAS Client (w/MVC 2)
> > >
> > > Hi,
> > >
> > > A redirect loop (browser detects infinite/broken redirection on
the
> > > page) is generally cookie related.  I haven't tested an app at the
> > root
> > > of the server...  I always did development in an application off
of
> > the
> > > root.  It's possible you've found a bug in the client.
> > >
> > > A re-login loop (you are prompted for CAS credentials over and
over
> > > again or you get stuck at the 'you are already logged in' CAS
page)
> > > could be ticket validation related, which are often SSL related.
> The
> > > log from the CAS server looks good as far as the CAS server
> assigning
> > a
> > > ticket.  You'll want to look at the logs on the proxyValidate step
> a
> > > few
> > > lines down from there.  proxyValidate requires that the CAS server
> > > trusts the entire SSL certificate chain of the app server.  The
CAS
> > > server makes a connection back to the app server over SSL as part
> of
> > > the
> > > CAS 2.0 protocol surrounding Proxy Granting Tickets.  I noticed
> your
> > > CAS
> > > server and your app server are both at sso-dev.foo.umd.edu.  I'm
> > > assuming that your /cas/login is the IIS-Tomcat bridge or
something
> > > like
> > > that.  You might want to look out for SSL related errors in the
CAS
> > > server logs.  It could be an issue that both the CAS server and
the
> > app
> > > server both have the same host name.  You might also try turning
> off
> > > proxy support by removing the ProxyTicketManager or setting the
> proxy
> > > option to false in the CAS configuration in web.config.  This
would
> > > cause the client to use serviceValidate instead, skipping the PGT
> > > handshake.  It will at least let you rule out SSL.
> > >
> > > Another possible, though highly unlikely cause is that somehow the
> > > FormsAuthenticationCookie > 4096 bytes which might cause your
> browser
> > > to
> > > ignore it.  Also, some browsers assign limits on the number of or
> > size
> > > of outstanding cookies to a particular domain.  If you're not
> > already,
> > > try using the CacheTicketManager.  It reduces the footprint of the
> > > cookie and stores more of the data on the server and less on the
> > > client.
> > > If you have other applications on that server that generate a
large
> > > number of cookies, you might try deleting your cookies for that
> > entire
> > > domain (sso-dev.foo.umd.edu).
> > >
> > > Keep me in the loop, especially if you think it looks like a bug
in
> > the
> > > client.  I'm trying to lock down a v1.0 release of the client
> shortly
> > > and would definitely want to address an issue of this severity
> before
> > > the release.
> > >
> > > -Scott
> > >
> > > > -----Original Message-----
> > > > From: Jason Edward White [mailto:[email protected]]
> > > > Sent: Friday, August 27, 2010 2:46 PM
> > > > To: Scott M. Holodak
> > > > Subject: RE: .Net CAS Client (w/MVC 2)
> > > >
> > > > Tried that ... it has to be at least one char. Also tried "/"
...
> > > same
> > > > redirect endless loop. Have traced it down to a
> > > > TicketValidationException (but no more detail than that yet) in
> > > > CasAuthentication.cs >> ProcessTicketValidation. the ...
> > > >
> > > >  try
> > > >             {
> > > >                 // Attempt to authenticate the ticket and
resolve
> > to
> > > an
> > > > ICasPrincipal
> > > >                 string serviceUrl =
> > > >
> > >
> >
>
UrlUtil.ConstructServiceUrl(RequestEvaluator.GetRequestHasGatewayParame
> > > > ter());
> > > >                 principal = TicketValidator.Validate(ticket,
> > > > serviceUrl);
> > > > ...
> > > >  }
> > > > catch (TicketValidationException t)
> > > >             {
> > > >                 Log.DebugFormat("******** ProcessTicketValiation
> -
> > > > TicketValidationException ({0}) ************", t.Message);
> > > >                 // Leave principal null.  This might not have
> been
> > a
> > > > CAS service ticket.
> > > > }
> > > >
> > > > The message sequence goes like this (mine has the *'s in it):
> > > >
> > > > 2010-08-27 14:38:20,437 [5] DEBUG CasAuthenticationModule -
> > Starting
> > > > BeginRequest for /Restricted/UsersRoleOnly/default.aspx
> > > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule -
> Ending
> > > > BeginRequest for /Restricted/UsersRoleOnly/default.aspx
> > > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule -
> > Starting
> > > > AuthenticateRequest for /Restricted/UsersRoleOnly/default.aspx
> > > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule -
> Ending
> > > > AuthenticateRequest for /Restricted/UsersRoleOnly/default.aspx
> > > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule -
> > Starting
> > > > EndRequest for /Restricted/UsersRoleOnly/default.aspx
> > > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule -
> > > > Redirecting to CAS Login Page
> > > > 2010-08-27 14:38:20,452 [5] DEBUG UrlUtil -
> > > ConstructServiceUrl:return
> > > > generated serviceUri: https://sso-
> > > > dev.foo.umd.edu/Restricted/UsersRoleOnly/default.aspx
> > > > 2010-08-27 14:38:20,452 [5] DEBUG UrlUtil -
> > > ConstructLoginRedirectUrl:
> > > > redirectToUrl=>https://sso-
> > > > dev.foo.umd.edu/cas/login?service=https%3a%2f%2fsso-
> > > > dev.foo.umd.edu%2fRestricted%2fUsersRoleOnly%2fdefault.aspx<
> > > > 2010-08-27 14:38:20,452 [5] DEBUG CasAuthenticationModule -
> Ending
> > > > EndRequest for /Restricted/UsersRoleOnly/default.aspx
> > > > 2010-08-27 14:38:20,515 [5] DEBUG CasAuthenticationModule -
> > Starting
> > > > BeginRequest for
> /Restricted/UsersRoleOnly/default.aspx?ticket=ST-
> > > 962-
> > > > dyFiQ7ahWVR4SyjyfOzE-cas
> > > > 2010-08-27 14:38:20,515 [5] DEBUG CasAuthenticationModule -
> Ending
> > > > BeginRequest for
> /Restricted/UsersRoleOnly/default.aspx?ticket=ST-
> > > 962-
> > > > dyFiQ7ahWVR4SyjyfOzE-cas
> > > > 2010-08-27 14:38:20,515 [5] DEBUG CasAuthenticationModule -
> > > Processing
> > > > Proxy Callback request
> > > > 2010-08-27 14:38:20,515 [5] DEBUG UrlUtil -
> > > ConstructServiceUrl:return
> > > > generated serviceUri: https://sso-
> > > > dev.foo.umd.edu/Restricted/UsersRoleOnly/default.aspx
> > > > 2010-08-27 14:38:20,515 [5] DEBUG AbstractUrlTicketValidator -
> > > > Validate:Constructed validation url:https://sso-
> > > >
> >
dev.foo.umd.edu/cas/proxyValidate?ticket=ST-962-dyFiQ7ahWVR4SyjyfOzE-
> > > > cas&service=https%3a%2f%2fsso-
> > > >
> > >
> >
>
dev.foo.umd.edu%2fRestricted%2fUsersRoleOnly%2fdefault.aspx&pgtUrl=http
> > > > s%3a%2f%2fsso-
> > > >
> > >
> >
>
dev.foo.umd.edu%2fRestricted%2fUsersRoleOnly%2fdefault.aspx%3fproxyResp
> > > > onse%3dtrue
> > > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthentication - ********
> > > > ProcessTicketValiation - TicketValidationException (CAS server
> > ticket
> > > > validation threw an Exception) ************
> > > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule -
> > Starting
> > > > AuthenticateRequest for
> > > > /Restricted/UsersRoleOnly/default.aspx?ticket=ST-962-
> > > > dyFiQ7ahWVR4SyjyfOzE-cas
> > > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule -
> Ending
> > > > AuthenticateRequest for
> > > > /Restricted/UsersRoleOnly/default.aspx?ticket=ST-962-
> > > > dyFiQ7ahWVR4SyjyfOzE-cas
> > > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule -
> > Starting
> > > > EndRequest for /Restricted/UsersRoleOnly/default.aspx?ticket=ST-
> > 962-
> > > > dyFiQ7ahWVR4SyjyfOzE-cas
> > > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule -
> > > > Redirecting from login callback
> > > > 2010-08-27 14:38:20,530 [5] DEBUG UrlUtil -
> > > RemoveCasArtifactsFromUrl:
> > > > redirectToUrl=>https://sso-
> > > > dev.foo.umd.edu/Restricted/UsersRoleOnly/default.aspx<
> > > > 2010-08-27 14:38:20,530 [5] DEBUG CasAuthenticationModule -
> Ending
> > > > EndRequest for /Restricted/UsersRoleOnly/default.aspx?ticket=ST-
> > 962-
> > > > dyFiQ7ahWVR4SyjyfOzE-cas
> > > >
> > > >
> > > > At the same time, the CAS server says (have already
authenticated
> > at
> > > > CAS in this scenario)
> > > > 2010-08-27 14:38:48,184 INFO
> > > > [org.jasig.cas.CentralAuthenticationServiceImpl] - <Granted
> service
> > > > ticket [ST-962-dyFiQ7ahWVR4SyjyfOzE-cas] for service
> [https://sso-
> > > > dev.foo.umd.edu/Restricted/UsersRoleOnly/default.aspx] for user
> > > > [jewhite]>
> > > >
> > > > Will keep digging and let you know what I come up with. There
has
> > to
> > > be
> > > > some explanation here ...
> > > >
> > > > ________________________________________
> > > > From: Scott M. Holodak [[email protected]]
> > > > Sent: Friday, August 27, 2010 2:04 PM
> > > > To: Jason Edward White; Scott M. Holodak
> > > > Subject: RE: .Net CAS Client (w/MVC 2)
> > > >
> > > > Try and remove the path attribute altogether for an app at the
> root
> > > of
> > > > the web server.
> > > >
> > > > > -----Original Message-----
> > > > > From: Jason Edward White [mailto:[email protected]]
> > > > > Sent: Friday, August 27, 2010 11:48 AM
> > > > > To: Scott M. Holodak
> > > > > Subject: RE: .Net CAS Client (w/MVC 2)
> > > > >
> > > > > This worked on the VS compiled version (running on  localhost)
> > ...
> > > I
> > > > > get the expected sequence:
> > > > > 1) Go to restricted area, redirect to CAS
> > > > > 2) Authenticate
> > > > > 3) Redirect back with ticket
> > > > > 4) Validate ticket
> > > > > 5) Strip and redirect w/o ticket
> > > > > 6) View restricted page
> > > > >
> > > > > ... but not on the server (where path should ="/").  Actually
> no
> > > > cookie
> > > > > seems to get issued there. I'm going to go put some more debug
> > code
> > > > and
> > > > > rebuild the client, but again wanted to see if you had any
> > > immediate
> > > > > insight.
> > > > >
> > > > > Thanks,
> > > > >
> > > > > Jason
> > > > > ________________________________________
> > > > > From: Scott M. Holodak [[email protected]]
> > > > > Sent: Thursday, August 26, 2010 5:05 PM
> > > > > To: Jason Edward White; Scott M. Holodak
> > > > > Subject: RE: .Net CAS Client (w/MVC 2)
> > > > >
> > > > > Hi,
> > > > >
> > > > > Check that the path property matches the URL of your web app.
> So
> > > if
> > > > > your web app is http://my.server.edu/example/, your path would
> be
> > > > > "/example/".  Otherwise the cookie is created for a different
> > path
> > > on
> > > > > your server and it's as if it was never created at all from
the
> > > > > application's perspective.
> > > > >
> > > > > -Scott
> > > > >
> > > > > <authentication mode="Forms">
> > > > >   <forms
> > > > >     loginUrl="https://cas.server.edu/cas/login";
> > > > >     timeout="30"
> > > > >     defaultUrl="~/Default.aspx"
> > > > >     cookieless="UseCookies"
> > > > >     slidingExpiration="true"
> > > > >     path="/example/" />
> > > > > </authentication>
> > > > >
> > > > > > -----Original Message-----
> > > > > > From: Jason Edward White [mailto:[email protected]]
> > > > > > Sent: Thursday, August 26, 2010 4:59 PM
> > > > > > To: Scott M. Holodak
> > > > > > Subject: RE: .Net CAS Client (w/MVC 2)
> > > > > >
> > > > > > Scott,
> > > > > >
> > > > > > Thanks again for sharing and the quick reply  ... I've been
> > > toying
> > > > > with
> > > > > > this in the time I have. I've got it *mostly* working, but
it
> > is
> > > > now
> > > > > > caught in an endless redirect loop after successfully
> > > > authenticating
> > > > > at
> > > > > > CAS. it's acting as if I don't have cookies set/allowed.
It's
> > as
> > > if
> > > > > > after setting the cookie and redirecting w/o the cas ticket,
> it
> > > > > doesn't
> > > > > > recognized the cookie.  I'm going to debug with a fresh log
> > > > tomorrow
> > > > > > AM, but wanted to see if you had experienced anything
similar
> > to
> > > > > this.
> > > > > >
> > > > > > The only config I have really changed is setting gateway to
> > false
> > > > and
> > > > > > modifying the URLs. The CAS side and ticket validation seem
> to
> > be
> > > > > > working fine.
> > > > > >
> > > > > > Thanks again,
> > > > > > Jason
> > > > > >
> > > > > > ________________________________________
> > > > > > From: Scott M. Holodak [[email protected]]
> > > > > > Sent: Friday, August 20, 2010 3:34 PM
> > > > > > To: Jason Edward White
> > > > > > Subject: RE: .Net CAS Client (w/MVC 2)
> > > > > >
> > > > > > Hi Jason,
> > > > > >
> > > > > > I would recommend grabbing the client code directly from the
> > SVN
> > > > > trunk.
> > > > > > We are planning a release shortly, but it should be stable.
> > > > > >
> > > > > > The basic gist of things is that the LogOn action normally
> > > doesn't
> > > > > have
> > > > > > an [Authorize] attribute.  It usually returns an HTML view
> that
> > > > asks
> > > > > > for
> > > > > > a username & password.  With the [Authorize] attribute, the
> CAS
> > > > > > authentication module kicks in (just as it would in a web
> forms
> > > > app),
> > > > > > redirects you to the CAS server, handles the redirect back
> from
> > > the
> > > > > CAS
> > > > > > server, gives you a FormsAuthenticationTicket/Cookie and
> > > redirects
> > > > > you
> > > > > > back to the original URL (the LogOn action again).  Now the
> > LogOn
> > > > > > action
> > > > > > is authorized & executes.  I just replaced the body with a
> > > > > > RedirectAction that takes you back to Index/Home.  The
LogOff
> > > > action
> > > > > is
> > > > > > pretty straightforward also.  I just modified the
> > > > > FormsService.SignOut
> > > > > > method slightly.
> > > > > >
> > > > > > CASifying the default ASP.NET MVC2 project was the first
> thing
> > I
> > > > had
> > > > > > ever done with MVC and I was pretty surprised with how easy
> it
> > > was.
> > > > > I
> > > > > > didn't get around to checking whether the same procedures
> apply
> > > to
> > > > > the
> > > > > > default ASP.NET MVC v1 project.  If you run into any
> questions
> > or
> > > > > > roadblocks, please let me know and/or post to cas-dev.  Also
> > > please
> > > > > > free
> > > > > > to edit the wiki page with your notes/experiences.  I'm
still
> > new
> > > > to
> > > > > > MVC
> > > > > > so I don't know whether it's all best practices on the
> > > application
> > > > > > level.  The HttpModule operates at a lower level and didn't
> > > require
> > > > > any
> > > > > > significant changes to support MVC.  I guess that's a good
> > thing
> > > :-
> > > > )
> > > > > >
> > > > > > Any feedback on/off-list or patches are greatly appreciated.
> > > > > >
> > > > > > Good luck!
> > > > > > -Scott
> > > > > >
> > > > > > > -----Original Message-----
> > > > > > > From: Jason Edward White [mailto:[email protected]]
> > > > > > > Sent: Friday, August 20, 2010 3:13 PM
> > > > > > > To: [email protected]
> > > > > > > Subject: .Net CAS Client (w/MVC 2)
> > > > > > >
> > > > > > > Scott,
> > > > > > >
> > > > > > > We are looking to implement some .Net code with CAS. I've
> > > looked
> > > > > all
> > > > > > > around and everything seems to point back to your info. on
> > the
> > > > > > > jasig.org site.  Ours is a is MVC 2 app.  I've looked over
> > your
> > > > > docs
> > > > > > on
> > > > > > > jasig.or (thanks for sharing).  Do I assume correctly,
that
> > you
> > > > > > should
> > > > > > > use the client/s at:
> > > > > > >
> > > > > > > https://wiki.jasig.org/display/CASC/.Net+Cas+Client
> > > > > > >
> > > > > > > in conjunction with your instructions at:
> > > > > > >
> > > > > > >
> https://wiki.jasig.org/pages/viewpage.action?pageId=32210981
> > > ...?
> > > > > > >
> > > > > > > Any help greatly appreciated. And if there is someway we
> can
> > > > > > > contribute, please let me know.
> > > > > > >
> > > > > > > Thanks,
> > > > > > > Jason
> > >
> > > --
> > > 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
> >
> >
> > --
> > 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
>
>
> --
> 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


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