Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

Delphi SOAP basic Security

89 views
Skip to first unread message

Robert Baker

unread,
Feb 16, 2003, 12:22:58 PM2/16/03
to
I looking for a straightforward "how-to" regarding implementing basic
security in a Delphi 7 Web Service. I do not necessarily want to use SSL
[its not out of the question] or anything complex just implement a simple
lock on the door as I am not guarding Fort Knox. I am building a simple
Intranet and I need to let remote uses to be able to sync their laptops
briefcase data but keep unintended hackers from access to this data. I've
got the functionality in place. now I just need to keep non-authorized users
out.

Thanks,

Robert Baker

Deepak Shenoy (TeamB)

unread,
Feb 17, 2003, 11:44:50 AM2/17/03
to

SSL will be good to keep packet sniffers at bay. Send the user's
authorization info (maybe a private key or a username/password) in the
headers (look for soap headers in D7) and validate those at the server.
--
Deepak Shenoy (TeamB)
Agni Software
http://www.agnisoft.com

Simon

unread,
Feb 21, 2003, 5:10:32 AM2/21/03
to
Are there any major security benfits to using the headers to store
information such as the username/password over just having a field in the
function calls?

I have a similar set-up, and I have been passing the userid over SSL, and
using the userid with some session management to validate the user. So if I
had a function called, GetUsrName which returns the name of the current
user, if would have the following signature...

function GetUsrName(const UsrID : Integer): WideString; stdcall;

if I used SOAP headers the UsrID field could be placed in the header and
could therefore be removed from the function signature. However, this
doesn't improve the security does it? Because of the header definition
appearing in the WSDL doc for the service?

An approach I thought of would be to 'hide' the variables, by either alter
the name of the variable so UsrID could be changed to summink like
CurrentDate, but this has the problem of being misleading. The alternative
would be to use the OnBeforePublishWSDL of the TWSDLHTMLPublish component to
intercept and alter then wsdl file so it doesn't show the variables you
would use, but I don't know how effective it would be, or if there are other
ways of determining what the service functions are without using the WSDL
file. Seeing as I wouldn't be expecting anyone who doesn't have access to
the source code to access the service, I'm not bothered about the WSDL file
appearing wrong, but I'm interested in what any of you guys have to say
about any of the points I have raised.

Sorry for the lengthy post,

Simon. :}

--
Remove the numbers to email me.


"Deepak Shenoy (TeamB)" <shenoy.donotspam@agnisoftdotcom> wrote in message
news:3e51...@newsgroups.borland.com...

Deepak Shenoy (TeamB)

unread,
Feb 21, 2003, 11:30:12 AM2/21/03
to
> Are there any major security benfits to using the headers to store
> information such as the username/password over just having a field in the
> function calls?

Not much at this time, but in the future web servers might have special
security features based on the soap header. (just thinking aloud here)

> if I used SOAP headers the UsrID field could be placed in the header and
> could therefore be removed from the function signature. However, this
> doesn't improve the security does it? Because of the header definition
> appearing in the WSDL doc for the service?

If you don't want to, simply don't publish the wsdl (remove the wsdl
component from your server web unit)

Simon

unread,
Feb 24, 2003, 5:19:36 AM2/24/03
to
Ahhh, ok, thanks for the info. I presume other than the WSDL doc that gets
generated there is no other way of determining the functions exported by
that service then?

Many thanks,

Simon.

--
Remove the numbers to email me.


"Deepak Shenoy (TeamB)" <shenoy.donotspam@agnisoftdotcom> wrote in message

news:3e56...@newsgroups.borland.com...

Deepak Shenoy (TeamB)

unread,
Feb 24, 2003, 7:03:18 AM2/24/03
to
> Ahhh, ok, thanks for the info. I presume other than the WSDL doc that gets
> generated there is no other way of determining the functions exported by
> that service then?

You can share the Interface file (.pas file) with any potential client,
since the interface definition is pretty much the same as what is generated
by Delphi using the WSDL.

Simon

unread,
Feb 24, 2003, 7:45:09 AM2/24/03
to
Yup, I know, sorry, I didn't make myself clear. I'm thinking in terms of
security, for example, whats the point in not displaying the WSDL if there's
some other way for a random user to access/list the exported functions? I'm
therefore presuming that because the web server intercepts the calls to the
service, that there is no way to quiz the webservice directly, other than
asking for the WSDL, like there's no method of doing something like
GetEntryPoint to obtain some raw info about the service and going from
there?

--
Remove the numbers to email me.


"Deepak Shenoy (TeamB)" <shenoy.donotspam@agnisoftdotcom> wrote in message

news:3e5a...@newsgroups.borland.com...

Deepak Shenoy (TeamB)

unread,
Feb 24, 2003, 10:28:40 AM2/24/03
to
> Yup, I know, sorry, I didn't make myself clear. I'm thinking in terms of
> security, for example, whats the point in not displaying the WSDL if
there's
> some other way for a random user to access/list the exported functions

No other way than the WSDL. A random user can't get to a function definition
without the WSDL, unless he already knows your function name, parameter
types, namespaces etc. There's nothing you can call on the soap service that
will give you a list of functions.

HTH,

0 new messages