Remote logon page like Microsoft passport

S

Steven Spits

Hi,

Our company has a database of users that we use to authenticate users on
various websites.

However, some of our customers want to develop a website on their own and
use the same database authenticate users.

At first I was thinking to create a WebService that accepts username &
password and returns if it's valid or not. But it is *very* important that
our customers don't know the password of these users. Because our customers
could "log" the data send to the webservice, this is obviously not a good
idea.

So I guess what we need is a system like Microsoft passport where the user
gets redirected to another website to logon and returns to the original url
afterwards.

What would be the best way to communicate between urls? It should be easy to
implement and yet secure.

Steven

- - -
 
B

Bruno Alexandre

you can always do this:

Client Web Form should have the action form using POST method to your page
in your server with 2 forms (user and pwd) and 2 hidden inputs ( clientID
and PostBackURL )

your page accepts by POST the clientID and check if there's a correct
clientID to use your function, if ok accept user and pwd, and get true or
false, and redirect again to PostBackURL

*************************************

or have the same, but the LOGIN page is in your server and you only accept,
ClientID and PostBackURL [or only ClientID and from the DB you know where to
redirect the user after a good authentication]

using this they never know username/pwd from your own clients

*************************************

.... did I miss anything?
hope the idea is exactly what you need...
 
S

Steven Spits

Bruno,
Client Web Form should have the action form using POST method to your page
in your server with 2 forms (user and pwd) and 2 hidden inputs ( clientID
and PostBackURL )

your page accepts by POST the clientID and check if there's a correct
clientID to use your function, if ok accept user and pwd, and get true or
false, and redirect again to PostBackURL

This way would allow the client to log input before sending it to us. So no,
not a good idea.
or have the same, but the LOGIN page is in your server and you only
accept, ClientID and PostBackURL [or only ClientID and from the DB you
know where to redirect the user after a good authentication]

using this they never know username/pwd from your own clients

This is what I meant when saying "like Microsoft passport". But I'm still
not sure how to make it secure?

For example, how do I test in PostBackURL that the user was authenticated
using *our* login page? Using parameters
("http://ClientServer/WebApp/Validated.aspx?UserID=12345") would be
insecure, unless both parties write some code to check if the querystring is
not tampered with (like
http://aspnet.4guysfromrolla.com/articles/083105-1.aspx). But I want
implementation to be as easy as possible so I'm not sure this is the way to
go...

Steven

- - -
 
B

Bruno Alexandre

steve that's why I told you to use POST instead of GET

POST does not give values in the URL Address... on GET

Web Client Application:

<form name="myform" id="myform" method="POST"
action="www.yourserver.com/loginpage.aspx">
<input type="hidden"
value="http://www.ClientWebServer.com/user/default.aspx" name="PostBackURL"
/>
<input type="hidden" value"iux876xj" name="CLientID" />
<a href="#" onclick="document.myform.submit();">Please click here to
login</a>
</form>

********************************************************************
Your loginpage.apx in you server

<%
Protected Sub Page_Load(ByVal sender As Object, ByVal e As
System.EventArgs)
Dim sClientID as String = request("ClientID")
if sClientID isnot nothing then
if validateClientID( sClientID ) then
' everything is ok, let's show the login page to the
user, but before let's keep the PostBackURL
session("RedirectTo") = request("PostBackURL")
else
' the clientID does not EXIST redirect the user with an
error
response.redirect("http://www.ClientWebServer.com/user/default.aspx?error=1",
true )
end if
end if
End Sub

Protected Sub btnLogin_Click(ByVal sender As Object, ByVal e As
System.EventArgs)
' imagine this is the event when the user click the LOGIN button
in this page
dim sUser as string = fUser.text.tostring
dim sPwd as string = fPwd.text.tostring

if validateUser(sUser, sPwd) then
response.redirect( session("PostBackURL"), true)
else
myErrorLabel.Text = "Invalid Username/Password!"
end if
End Sub
%>


got it?...

if you still have doubts, send me an email ([email protected]) and I
will send you 2 pages with this working.

--

Bruno Alexandre
(a Portuguese in Københanv, Danmark)


Steven Spits said:
Bruno,
Client Web Form should have the action form using POST method to your
page in your server with 2 forms (user and pwd) and 2 hidden inputs (
clientID and PostBackURL )

your page accepts by POST the clientID and check if there's a correct
clientID to use your function, if ok accept user and pwd, and get true or
false, and redirect again to PostBackURL

This way would allow the client to log input before sending it to us. So
no, not a good idea.
or have the same, but the LOGIN page is in your server and you only
accept, ClientID and PostBackURL [or only ClientID and from the DB you
know where to redirect the user after a good authentication]

using this they never know username/pwd from your own clients

This is what I meant when saying "like Microsoft passport". But I'm still
not sure how to make it secure?

For example, how do I test in PostBackURL that the user was authenticated
using *our* login page? Using parameters
("http://ClientServer/WebApp/Validated.aspx?UserID=12345") would be
insecure, unless both parties write some code to check if the querystring
is not tampered with (like
http://aspnet.4guysfromrolla.com/articles/083105-1.aspx). But I want
implementation to be as easy as possible so I'm not sure this is the way
to go...

Steven

- - -
 
S

Steven Spits

Bruno Alexandre said:
steve that's why I told you to use POST instead of GET
POST does not give values in the URL Address... on GET

There is no difference in using POST or GET. Both can be tampered with.

I think you misunderstood me. The QueryString I used as an example is the
one *after* validation. Like this one on your code:
if validateUser(sUser, sPwd) then
response.redirect( session("PostBackURL"), true)
else
myErrorLabel.Text = "Invalid Username/Password!"
end if
End Sub

I want to return to the client WHO was authenticated. And I also want to
make sure in "PostBackURL" that the user was actually validated and didn't
typed that URL directly in his browser.

I appreciate your help...!

Steven

- - -
 
B

Bruno Alexandre

You can temper the Passport URL's... but what's the point? you will not be
validated!

sincerelly I thing you are putting too much in a really simple thing!
you problem is the username and password (as in Passport) and that YOU CAN
NOT temper as I told you!

soon you are login in your client could set a session to true and only show
the postbackurl page if the sessionID is the same that you can send him
back, for example...

like:

http://www.ClientWebServer.com/user/iuqwqwe7098709870qweyoqywe/default.aspx


and youre client must use redirect em asp.net to show the content, that's
called URL Mapping

in the HOW DO I: Microsoft Video Series, you have this in the Tips & Tricks
VIDEO (this particulary part stars at 14.05'')

http://msdn.microsoft.com/asp.net/learning/learn/newtodevelopment/default.aspx
 
S

Steven Spits

Bruno Alexandre said:
You can temper the Passport URL's... but what's the point? you will not be
validated!

We are clearly talking about something else.

Like I said before twice, *AFTER* validation I want to return to the calling
webserver and indicate WHO logged on. Tampering with this information (POST
or GET doesn't matter) has a very good point because I can fool the
webserver I got validated correctly as someone else!
sincerelly I thing you are putting too much in a really simple thing!

One can never put enough effort in security.
you problem is the username and password (as in Passport) and that YOU CAN
NOT temper as I told you!

The validation itself happens on my server, so I'm not afraid of any
tampering here...
soon you are login in your client could set a session to true and only
show the postbackurl page if the sessionID is the same that you can send
him back, for example...

....not sure what you mean here? How can a SessionID help me? We're talking
different servers here.
and youre client must use redirect em asp.net to show the content, that's
called URL Mapping

I'm familiar with url mapping, but I'm not sure how this is going to help
me? Url mapping is just another way to send parameters, only less visible to
the user.

Steven

- - -
 
B

bruce barker \(sqlwork.com\)

the best is to pass back an authenciation ticket in the URL. you should
encrypt the ticket with a key only known to the requesting site.


-- bruce (sqlwork.com)
 
S

Steven Spits

Bruno,

I appreciate your help, but if you don't *read* my mails, we're getting
nowhere...
I just loged in from Expression product and the URL to the LOGIN form is:

For the third time: the problem is not the url *TO* the login form, it's the
url *GOING BACK* from the login page to site that originally requested the
authentication.

Based on your example: what happens when I copy & paste the value of "ru" in
my browser? How to check if the user was actually validated?

Steven

- - -
 
S

Steven Spits

bruce barker (sqlwork.com) said:
the best is to pass back an authenciation ticket in the URL. you should
encrypt the ticket with a key only known to the requesting site.

Yes, probably this is the way to go.

I does mean both parties will have to agree on an encryption technology.
Because it probably will not always be .NET vs .NET I'm not sure what would
be my best option...

Steven

- - -
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Members online

Forum statistics

Threads
473,774
Messages
2,569,596
Members
45,143
Latest member
DewittMill
Top