.NETGURU
  Search:  
NamespacesDiscussions.NET v1.1Dot Net Guru's BlogIT Certification
Forms Authentication ReturnURL
Messages   Related Types
This message was discovered on ASPFriends.com 'aspngsec' list.


Chuck Peper
In forms authtentication Information about the originating page where
access was requested is placed in the query string using RETURNURL as
the key.

In beta1 this contained the entire URL. In the release this contains
the path but not the web site.

If you are using forms authentication across multiple websites. How do
you know what the originating page is?
Reply to this message...
 
    
Brad Kingsley
I do not believe it is possible to use a single site to authenticate for
multiple sites (domains) without using customized authentication processes.
Even then I think you would have some security issues.

~Brad Kingsley
Microsoft MVP - ASP
Windows 2000 MCSE

http://www.orcsweb.com/
Powerful Web Hosting Solutions
#1 in Service and Support

----- Original Message -----
From: "Chuck Peper" <Click here to reveal e-mail address>
Newsgroups: aspngsec
To: "aspngsec" <Click here to reveal e-mail address>
Sent: Monday, July 22, 2002 12:41 PM
Subject: [aspngsec] Forms Authentication ReturnURL

[Original message clipped]
Reply to this message...
 
    
Chuck Peper
It's possible, because I did it in beta1 and in the release. As long as
the other site can access the cookie you're fine (same realm). If I put
the forms authentication code on every web site it works, but that
doesn't make sense from a configuration management standpoint; I don't
want our authentication code on hundreds of web sites.

That's the purpose behind having the
<machineKey
validationKey="12439488932589403841"
decryptionKey="48643494647822246876" >
</machineKey>
so you can read the cookie on other sites.

Unfortunately MS blew it for enterprise deployments by changing the
value returned in the ReturnURL.

p.s. Http_referrer, doesn't work.

In article <687332@aspngsec>, Click here to reveal e-mail address says...
[Original message clipped]
Reply to this message...
 
    
Alex Dresko
Can you clarify this question a little? I might be able to help but I
don't understand what you mean by using forms authentication across
multiple websites.

Alex Dresko
Three Point Oh!

-----Original Message-----
From: Chuck Peper [mailto:Click here to reveal e-mail address]
Sent: Monday, July 22, 2002 12:41 PM
To: aspngsec
Subject: [aspngsec] Forms Authentication ReturnURL

In forms authtentication Information about the originating page where
access was requested is placed in the query string using RETURNURL as
the key.

In beta1 this contained the entire URL. In the release this contains
the path but not the web site.

If you are using forms authentication across multiple websites. How do
you know what the originating page is?

| [aspngsec] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngsec.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
Reply to this message...
 
    
Chuck Peper
I have a Centralized authentication Web Server that does NTLM,
Kerberos/Unix, and API (LogOnUser for Netscape guys) authentication. On
Authentication they are issued a FormsAuthentication Cookie.

Content web sites/servers all use Forms Authentication and are given the
URL of the Centralized authentication Web Server.

So we have one server that is used for authentication and many servers
for content. This works well because Configuration Management of the
authentication code is centrailized. Web authors needing authenticated
access just need to know the address of the authentication server and
the cookie decryption keys.

In beta 1 this worked great because we could send the users back to the
page they requested. With the release we know the dir and page they
came from but not the website.

beta 1 ReturnURL =website/dir/page
release ReturnURL = dir/page

The response.http_referrer does not contain the referring page (the user
never really made it their yet).

In article <687389@aspngsec>, Click here to reveal e-mail address says...
[Original message clipped]
Reply to this message...
 
    
Daniel Kent
You can synchronize the <machineKey> elements so that the forms
authentication tickets issued by one web application are accepted by another
(e.g. on another server).

You will also have to ensure that the servers are in the same domain -
things get a *lot* more complicated if you want to work across domains as
the authentication cookie is limited to one domain.

In Professional ASP.NET Security (Out in August) we include an example of
using this technique so that employees of a company can log into an
authentication server (inside the firewall) to get an authentication ticket
and then access a public site (on server in the DMZ) with administrative
access. There is no login code on the public server so it cannot issue
authentication tickets - it can only make use of those issued by the private
server.

Dan.

-----Original Message-----
From: Brad Kingsley [mailto:Click here to reveal e-mail address]
Sent: 23 July 2002 14:06
To: aspngsec
Subject: [aspngsec] Re: Forms Authentication ReturnURL

I do not believe it is possible to use a single site to authenticate for
multiple sites (domains) without using customized authentication processes.
Even then I think you would have some security issues.

~Brad Kingsley
Microsoft MVP - ASP
Windows 2000 MCSE

http://www.orcsweb.com/
Powerful Web Hosting Solutions
#1 in Service and Support

----- Original Message -----
From: "Chuck Peper" <Click here to reveal e-mail address>
Newsgroups: aspngsec
To: "aspngsec" <Click here to reveal e-mail address>
Sent: Monday, July 22, 2002 12:41 PM
Subject: [aspngsec] Forms Authentication ReturnURL

[Original message clipped]

| [aspngsec] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngsec.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
Reply to this message...
 
    
Brad Kingsley
But cookies are tied to a domain name, so I don't understand how one domain
could pull the cookie set on a different domain. MachineKey and
DecryptionKey are for spanning ASP.Net code across cluster nodes that all
respond to the same domain name.

~Brad Kingsley
Microsoft MVP - ASP
Windows 2000 MCSE

http://www.orcsweb.com/
Powerful Web Hosting Solutions
#1 in Service and Support

----- Original Message -----
From: "Chuck Peper" <Click here to reveal e-mail address>
Newsgroups: aspngsec
To: "aspngsec" <Click here to reveal e-mail address>
Sent: Tuesday, July 23, 2002 9:40 AM
Subject: [aspngsec] Re: Forms Authentication ReturnURL

[Original message clipped]
Reply to this message...
 
    
Chuck Peper
Cookies are valid for the realm specified in the cookie, which is
typically something like company.com. So all of your cookies in an
intranet environment in IE will be in the file:
\document and settings\username\cookies\company.txt

They are all accessible to any website at company.com (e.g.,
HR.company.com, ops.company.com, etc.)

In article <687617@aspngsec>, Click here to reveal e-mail address says...
[Original message clipped]
Reply to this message...
 
    
Chuck Peper
Already did that.

You might want to check your code before it goes to press though.
Like in my original post the RETURNURL parameter now only contains the
dir and page. Not the website, dir, and page. So after you issue your
cookie if you response.redirect(Request("ReturnURL")) you won't be going
back to the webserver where the page request was made, you'll be
redirected to the authentication servers directory/page of the same name
(if there is a page by that name)

In article <687579@aspngsec>, Click here to reveal e-mail address says...
[Original message clipped]
Reply to this message...
 
    
Chuck Peper
Thanks for the help gentlemen.
Here is my work around do to the changes in the ResponseURL property
between Beta1 and the release version.

The client web site must also have the following code in the
global.asax. This is because the RequestURL passed in the request
string contains the path to the requesting web page and NOT the entire
URL.

Sub Application_AuthenticateRequest
' Fires upon attempting to authenticate the use
If Not Request.IsAuthenticated Then
Dim ck As HttpCookie
ck = New HttpCookie(FormsAuthentication.FormsCookieName())
ck.Values("RequestURL") = Request.Url.AbsoluteUri
Response.Cookies.Add(ck)
End If
End Sub

This cookie is then read during the formsauthentication page load and is
used to redirect the user back to the requesting page.
Reply to this message...
 
    
Ben Lowery
you can issue a cookie that's good for a whole domain subtree (like
*.foo.com) and then access that cookie from any site within foo.com.
for instance, if you have login.foo.com issue a cookie with it's
domain property set to .foo.com, you could access that cookie from
www.foo.com and secure.foo.com and my.silly.domain.foo.com just fine.

as long as everything lives in one subtree, you're fine.

btw, anyone with a couple .co.uk addresses want to try something for
me? if i issue a cookie from foo.co.uk, can bar.co.uk see it?

--b

----- Original Message -----
From: "Brad Kingsley" <Click here to reveal e-mail address>
To: "aspngsec" <Click here to reveal e-mail address>
Sent: Tuesday, July 23, 2002 2:41 PM
Subject: [aspngsec] Re: Forms Authentication ReturnURL

> But cookies are tied to a domain name, so I don't understand how one
domain
[Original message clipped]
Reply to this message...
 
    
Daniel Kent
The code in my example doesn't need to use a return URL from one site to
another - the usage scenario is that employees log in with the private
server and then when they visit the public server, products on the ecommerce
site have extra option links displayed that link back to the private admin
server.

So, the public server does programmatic authorization to decide whether to
display the links. As users are never denied access to pages on the public
server through authorization, the returnurl issue is not encountered.

Dan.

-----Original Message-----
From: Chuck Peper [mailto:Click here to reveal e-mail address]
Sent: 23 July 2002 20:40
To: aspngsec
Subject: [aspngsec] Re: Forms Authentication ReturnURL

Already did that.

You might want to check your code before it goes to press though.
Like in my original post the RETURNURL parameter now only contains the
dir and page. Not the website, dir, and page. So after you issue your
cookie if you response.redirect(Request("ReturnURL")) you won't be going
back to the webserver where the page request was made, you'll be
redirected to the authentication servers directory/page of the same name
(if there is a page by that name)

In article <687579@aspngsec>, Click here to reveal e-mail address says...
[Original message clipped]

| [aspngsec] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngsec.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
Reply to this message...
 
    
Daniel Kent
According to the original netscape cookie specs, this should not work - just
like you can't issue a cookie for .com, .org and so on.

Cookie domains that end in 'big seven' TLDs (.com, .org, .net etc) have to
in a subdomain (e.g wrox.com). Cookie domains in other TLDs (e.g. .uk) have
to be in a subdomain of a subdomain (e.g. wrox.co.uk).

If browsers follow this rule then they should never send cookie set in
domains such as .co.uk.

Its possible that there are browsers that don't follow this principle
though...

Dan.

Professional ASP.NET Security - Out in August!

-----Original Message-----
From: Ben Lowery [mailto:Click here to reveal e-mail address]
Sent: 23 July 2002 23:57
To: aspngsec
Subject: [aspngsec] Re: Forms Authentication ReturnURL

you can issue a cookie that's good for a whole domain subtree (like
*.foo.com) and then access that cookie from any site within foo.com.
for instance, if you have login.foo.com issue a cookie with it's
domain property set to .foo.com, you could access that cookie from
www.foo.com and secure.foo.com and my.silly.domain.foo.com just fine.

as long as everything lives in one subtree, you're fine.

btw, anyone with a couple .co.uk addresses want to try something for
me? if i issue a cookie from foo.co.uk, can bar.co.uk see it?

--b

----- Original Message -----
From: "Brad Kingsley" <Click here to reveal e-mail address>
To: "aspngsec" <Click here to reveal e-mail address>
Sent: Tuesday, July 23, 2002 2:41 PM
Subject: [aspngsec] Re: Forms Authentication ReturnURL

> But cookies are tied to a domain name, so I don't understand how one
domain
[Original message clipped]

| [aspngsec] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngsec.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
Reply to this message...
 
    
Daniel Kent
Just to clarify - my last email was in relation to the BTW in Ben's email
not the main part - the subtree stuff works just fine.

Dan.

Professional ASP.NET Security - Out in August!

-----Original Message-----
From: Daniel Kent [mailto:Click here to reveal e-mail address]
Sent: 24 July 2002 10:27
To: aspngsec
Subject: [aspngsec] Re: Forms Authentication ReturnURL

According to the original netscape cookie specs, this should not work - just
like you can't issue a cookie for .com, .org and so on.

Cookie domains that end in 'big seven' TLDs (.com, .org, .net etc) have to
in a subdomain (e.g wrox.com). Cookie domains in other TLDs (e.g. .uk) have
to be in a subdomain of a subdomain (e.g. wrox.co.uk).

If browsers follow this rule then they should never send cookie set in
domains such as .co.uk.

Its possible that there are browsers that don't follow this principle
though...

Dan.

Professional ASP.NET Security - Out in August!

-----Original Message-----
From: Ben Lowery [mailto:Click here to reveal e-mail address]
Sent: 23 July 2002 23:57
To: aspngsec
Subject: [aspngsec] Re: Forms Authentication ReturnURL

you can issue a cookie that's good for a whole domain subtree (like
*.foo.com) and then access that cookie from any site within foo.com.
for instance, if you have login.foo.com issue a cookie with it's
domain property set to .foo.com, you could access that cookie from
www.foo.com and secure.foo.com and my.silly.domain.foo.com just fine.

as long as everything lives in one subtree, you're fine.

btw, anyone with a couple .co.uk addresses want to try something for
me? if i issue a cookie from foo.co.uk, can bar.co.uk see it?

--b

----- Original Message -----
From: "Brad Kingsley" <Click here to reveal e-mail address>
To: "aspngsec" <Click here to reveal e-mail address>
Sent: Tuesday, July 23, 2002 2:41 PM
Subject: [aspngsec] Re: Forms Authentication ReturnURL

> But cookies are tied to a domain name, so I don't understand how one
domain
[Original message clipped]

| [aspngsec] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngsec.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives

| [aspngsec] member Click here to reveal e-mail address = YOUR ID
| http://www.asplists.com/asplists/aspngsec.asp = JOIN/QUIT
| http://www.asplists.com/search = SEARCH Archives
Reply to this message...
 
    
Brian Trexler
Reading this entire discussion is so amusing. I'm having the same problem as the original posting... the center of the problem is the RedirectUrl but you guys keep talking about cookies. Forget about the machineKey stuff, I think we're beyond that. When you redirect to a login page that is on a different subdomain, after successful login .NET redirects you back to the same server as the login page is on (rather than the orginal page you're trying to access on a different subdomain).

In .NET, RedirectUrl does not contain the hostname (ie. http://xxx.foo.bar) so it can't redirect from subdomain to subdomain. This limits one's ability to have a centralized login server that is different from the context servers. Assuming cookies are accessible to everyone, it just doesn't redirect to the right server.

--------------------------------
From: Brian Trexler
Reply to this message...
 
 
System.Web.HttpCookie
System.Web.Security.FormsAuthentication




ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
Ad


Need Dot Net Interview Questions?
Ask ExamGuru, Inc. for advice and help on Passing .Net Interviews
.Net Projects
Best-of-breed application framework for .NET projects, developed by ExamGuru, Inc. and ExamGuru IT
Free .net Help
Commission ExamGuru, Inc. and his team for your next bespoke software project
FogBUGZ
The only bug tracking system carefully crafted with one goal in mind: helping teams create great software.
Awesome Tools
If you don't know about these, you're missing out... IT Certification Questions
IT Interview Questions
Free Oracle 10g Training
MCSE Boortcamp
Cisco Study Guides
Cheap Study Guides
Exact Questions
Dot Net Interview Questions
Oracle OCP
Cheap Travel
Designer Perfumes - Wholesale Prices
Free Programming Tutorials
 
ExamGuru IT Solutions - .Net Guru is owned and operated by ExamGuru, Inc., the man behind .Net Guru. If you're in the market for bespoke software or software consultancy, why not get him and his highly trained team to help? - www.examguru.net/ITCertification
 Copyright © ExamGuru, Inc. 2001-2006
Contact Us - Terms of Use - Privacy Policy - www.dot-net-guru.com - www.examguru.net - www.oraclesource.net - www.itinterviews.net - www.examguru.net/ITCertification