Implementing subscription based Web Service

[Guest]

Hello,

Sorry for the repost, I haven’t got any response in aspnet.webservices group.

We have a web service being used by several clients. It's SSL secured, uses
Windows (Basic) Authentication, each client has its own login. The management
wants to expend it to other clients, but provide "subscription based"
service. Where one pays a monthly fee to use it.
Now, I suggested using existing infrastructure Basic Authentication, just
disable Windows account when subscription expires. But management wants as
little administration as possible. Sure, I can create a user table in db, but
would not it be as much admin? Someone would still have to sign clients up
and enter new user names into database through some admin app or other wise.
If anyone had any experiences implementing Subscription based web service I
would like to hear your comments.

Thank you

 

[Guest]

Actually, using a table would be less administration. In the table that
contains the credentials:

e.g.
UserName (plain text string)
Password (sha1 hash hexcode string)
SubscriptionLastUpdated (datetime)
[other columns...]

As users pay for new/updated subscriptions, the SubscriptionLastUpdated
would automatically get repopulated with a current timestamp. Then on access
to the web service, you would query that table to see if that particular
user's SubscriptionLastUpdated value is more than 30 days ago... if so, you
would not allow access. This would be much easier than having to have
employees go in and scan through everyone's subscription records looking for
outdated subscriptions on a regular basis, and then going in and disabling
accounts using Computer Management or whatever interface is supplied to them.

 

[Guest]

Right, that makes sense.
But one would still have to add a new user to a table, perhaps through some
kind of admin tool. Enrollment will not be 100% automatic anyway.
Add/remove Windows user can also be done programaticlly though Admin tool.
But what you suggested does make sense. We need to store subscription info
somewhere anyway, database seems to be the right place. So might as well
store user name/passwords and expiration dates.
Thanks.

Actually, using a table would be less administration. In the table that
contains the credentials:

e.g.
UserName (plain text string)
Password (sha1 hash hexcode string)
SubscriptionLastUpdated (datetime)
[other columns...]

As users pay for new/updated subscriptions, the SubscriptionLastUpdated
would automatically get repopulated with a current timestamp. Then on access
to the web service, you would query that table to see if that particular
user's SubscriptionLastUpdated value is more than 30 days ago... if so, you
would not allow access. This would be much easier than having to have
employees go in and scan through everyone's subscription records looking for
outdated subscriptions on a regular basis, and then going in and disabling
accounts using Computer Management or whatever interface is supplied to them.

Hello,

Sorry for the repost, I haven’t got any response in aspnet.webservices group.

We have a web service being used by several clients. It's SSL secured, uses
Windows (Basic) Authentication, each client has its own login. The management
wants to expend it to other clients, but provide "subscription based"
service. Where one pays a monthly fee to use it.
Now, I suggested using existing infrastructure Basic Authentication, just
disable Windows account when subscription expires. But management wants as
little administration as possible. Sure, I can create a user table in db, but
would not it be as much admin? Someone would still have to sign clients up
and enter new user names into database through some admin app or other wise.
If anyone had any experiences implementing Subscription based web service I
would like to hear your comments.

Thank you

 

[Steven Nagy]

I have a quesiton following on to this...

If I had a user table based authentication, how could I make the web
service remember that someone is authenticated? Does session work the
same as it does for ASP.NET ? (I am guessing it does).

So the process would be for my client app to:
A) Call a Login method of the webservice, passing a username/pass and
getting a bool response.
B) If bool is true, then follow up with other calls.

Previously I had the username and password passed with EVERY method,
checking authentication on every query.
Example, get a list of outstanding messages, would call 'GetInbox'
method by passing a user name and password, but with the above process
I could store the userID in session right? Then my 'GetInbox' method
wouldn't need any parameters at all.

How then could I deal with session expiring and so on? Call some sort
of keep alive method as well? That method wouldn't even need any code
in it right? The simple fact that my client app has called the service
has renewed its session lease (or whatever the terminology is).

Is there any security issues relating to this form of authentication?

Many thanks,
Steven Nagy

 

[=?ISO-8859-1?Q?Henrik_G=F8ttig?=]

Hi Steven

Previously I had the username and password passed with EVERY method,
checking authentication on every query.

Do you send it as an argument to the web service?
If yes, I would suggest letting the security framework handle this for
you. Autentification info is then stored in the SOAP headers and is
invisible in the web service API.
If no, sorry...

At least I think so, but if you use frameworks as WSE or WCF (Indigo)
you can let the security subsystems of these framework handle
authentification. I think they implement some sort of "recogniztion" of
an already authenticated user on the serverside. Client side you assign
a "UserNameToken" to the request an it is this token that gets
authenticated.
Maybe some guys (or gals) can shed some light on this..maybe in another
group..?

Regards

Henrik

 

[clintonG]

Wouldn't ASP.NET 2.0 Membership, Roles and Profiles be ideally suited for
this objective?

<%= Clinton Gallagher
METROmilwaukee (sm) "A Regional Information Service"
NET csgallagher AT metromilwaukee.com
URL http://metromilwaukee.com/
URL http://clintongallagher.metromilwaukee.com/

 

[Guest]

:

I have a quesiton following on to this...

Previously I had the username and password passed with EVERY method,
checking authentication on every query.
Example, get a list of outstanding messages,

That's somehting I was just thinking about. I think that's the way I am
going to go; authentication with each request. That's just a nature of this
app. It's a windows client, user fetch chunks of data and work with it, there
can be 10 - 1hr time difference between each call and then user decides to
take a lunch break or leaves his/her machine on over the weekend with the
client running. I dont think it makes sense to keep session alive that long.

But to answer your question Session is very much part of Web Service .NET
application. Though clients must be able to accept cookies, from what I
understand.