|
| Forms Authentication ReturnURL |
|
|
|
|
| Messages |
|
Related Types |
This message was discovered on ASPFriends.com 'aspngsec' list.
| Chuck Peper |
| GOOD ANSWER |
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?
|
|
|
| |
|
|
| |
| |
| Brad Kingsley |
| GOOD ANSWER |
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]
|
|
|
| |
|
|
| |
|
| |
| Chuck Peper |
| GOOD ANSWER |
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]
|
|
|
| |
|
|
| |
|
| |
| Alex Dresko |
| GOOD ANSWER |
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
|
|
|
| |
|
|
| |
|
| |
| Chuck Peper |
| GOOD ANSWER |
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]
|
|
|
| |
|
|
| |
|
| |
| Daniel Kent |
| GOOD ANSWER |
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
|
|
|
| |
|
|
| |
|
| |
| Brad Kingsley |
| GOOD ANSWER |
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]
|
|
|
| |
|
|
| |
|
| |
| Chuck Peper |
| GOOD ANSWER |
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]
|
|
|
| |
|
|
| |
|
| |
| Chuck Peper |
| GOOD ANSWER |
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]
|
|
|
| |
|
|
| |
|
| |
| Chuck Peper |
| GOOD ANSWER |
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.
|
|
|
| |
|
|
| |
|
| |
| Ben Lowery |
| GOOD ANSWER |
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]
|
|
|
| |
|
|
| |
|
| |
| Daniel Kent |
| GOOD ANSWER |
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
|
|
|
| |
|
|
| |
|
| |
| Daniel Kent |
| GOOD ANSWER |
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
|
|
|
| |
|
|
| |
|
| |
| Daniel Kent |
| GOOD ANSWER |
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
|
|
|
| |
|
|
| |
| |
| Brian Trexler |
| GOOD ANSWER |
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
|
|
|
| |
|
|
| |
|
|
|
|
|
|
|
|
|
BootFX
Reliable and powerful .NET application framework. |
|
|
|
|
|
|
