Security Implementation

[Nick]

I am working on an application for a client that will involve using remoting.
They do not want to use integrated security so I was going to store
usernames and hashed passwords in a SQL Database. I have a table in the
database that will also contain their session information which it will
encrypt and store as a class on the client end. Each time they connect to
the server I will pass the session class back and it will decrypt, then
validate it...similar to FormsAuthenticaion in ASP.net. The reason for
storing the session info in the DB is that the client may cluster the remoted
component in the future and i would like to prepair for that. I will have a
validation class that my remoted objects will tie into which will have a
ValidateUser method as well as a InRole method to check for permissions.
Being that the server(s) running the remoted components will be the only
items exposed and not the database the only way data can be accessed is via
the remoted objects. My question is there a recommended way of using remoting
with usernames and passwords stored in the SQL Database better than what I am
doing or is my way pretty secure? I would love to hear any ideas that you
may have and am open to any suggestions that could make for a more secure
product.

Thanks in advance...

[William Stacey [MVP]]

Your needs may dictate otherwise, but much of all this can be had today with
WSE and using one of the security token types (UserName, SCT, Kerberos, etc)
and the local SAM or AD. This is about the 4th post I have seen today with
folks wanting to use SQL to store usernames/passwords. I am just curious if
people don't know they can leverage the windows account DB or if they think
that is an issue somehow? Anyway, if you go the WSE route, you can secure
all method calls by requiring a UserName token or a SecurityContextToken. A
SCT is more secure, but does require a server cert or you can use my method
below using just an RSA key pair generated for your app (i.e. the one you
strong-name-sign your assem with will work great.) WSE will automatically
validate the sent token against windows or you can override the validation
yourself using Win32 LogonUser api or custom DB. You could also set the
Thread.CurrentPrincipal to an authenticated Principal object and use the
CLR's Rules-Based security on your methods (declarative) or in the code
(imperative) for user/role checking.

Myself, I would just use SAM/AD as you can leverage all the tools already
built that staff already knows. Now you have a loosely coupled web service
that can be called locally or via the INET (if you so choose) that is
secured using the WS-* standards. And it is message based security, not
point-to-point security, so you can route messages with security intact and
save them, etc. Indigo will make all this even easier, but for now, WSE 2.0
is pretty sweet IMHO. They also have examples of caching SCT tokens in a DB
for web farm apps, so this sounds like a good fit for your needs.

Get SCT using RSA (no cert).
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Nick" <nt********@online.nospam> wrote in message
news:80**********************************@microsof t.com...

I am working on an application for a client that will involve using
remoting.
They do not want to use integrated security so I was going to store
usernames and hashed passwords in a SQL Database. I have a table in the
database that will also contain their session information which it will
encrypt and store as a class on the client end. Each time they connect to
the server I will pass the session class back and it will decrypt, then
validate it...similar to FormsAuthenticaion in ASP.net. The reason for
storing the session info in the DB is that the client may cluster the
remoted
component in the future and i would like to prepair for that. I will
have a
validation class that my remoted objects will tie into which will have a
ValidateUser method as well as a InRole method to check for permissions.
Being that the server(s) running the remoted components will be the only
items exposed and not the database the only way data can be accessed is
via
the remoted objects. My question is there a recommended way of using
remoting
with usernames and passwords stored in the SQL Database better than what I
am
doing or is my way pretty secure? I would love to hear any ideas that you
may have and am open to any suggestions that could make for a more secure
product.

Thanks in advance...

[Steven Cheng[MSFT]]

Thanks a lot for William's informative inputs.

Hi Nick,

As William has mentioned, if you're interested in the webservcie/SOAP
approach, the Microsoft's WebService Enhancement WSE has provide the
implementation of the latest WS-Security specification defined by
IBM,Microsoft.

Also, you mentioned in the first message that your application is using a
remoting object at serverside as a facade to retrieve datas from database
and expose to client apps. If so, I think we may need to implement our own
custom
security channels to secure our datas because the current version of .NET
REmoting (.net framework 1.x) is a very basic implementation which just
provide the rich functionality for remote appdomain to communicate with
eachother. There hasn't been any buildin security mechanism in .net
remoting.

As far as I knew, there has been may tech articles in MSDN discussing on
providing a plugable security channel for .net remoting communication
through the custom ChannelSink in .net remoting. Something like a
simplified version of SSL, we can register a ChannelSink in our remoting
client and server's ChannelSinks. This sink will use asymmetric encyption
to do the negotiate which confirm the symmetric encryption session key on
both side of the remoting connection. After that, all the data transfering
between client and server and encypted through the symmetric encryption.
Not sure whether you've already read the following articles, I think
that'll be helpful:

#.NET Remoting Authentication and Authorization Sample ¨C Part II
http://msdn.microsoft.com/library/en...asp?frame=true

#Secure Your .NET Remoting Traffic by Writing an Asymmetric Encryption
Channel Sink
http://msdn.microsoft.com/msdnmag/is....asp?frame=tru
e

Hope also helps. Thanks,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)

[Nick]

Do you know of any articles and / resources that talk about how to implement
the CustomTokens as well as using custom principals to work with the
passwords stored in SQL.

"William Stacey [MVP]" wrote:

Your needs may dictate otherwise, but much of all this can be had today with
WSE and using one of the security token types (UserName, SCT, Kerberos, etc)
and the local SAM or AD. This is about the 4th post I have seen today with
folks wanting to use SQL to store usernames/passwords. I am just curious if
people don't know they can leverage the windows account DB or if they think
that is an issue somehow? Anyway, if you go the WSE route, you can secure
all method calls by requiring a UserName token or a SecurityContextToken. A
SCT is more secure, but does require a server cert or you can use my method
below using just an RSA key pair generated for your app (i.e. the one you
strong-name-sign your assem with will work great.) WSE will automatically
validate the sent token against windows or you can override the validation
yourself using Win32 LogonUser api or custom DB. You could also set the
Thread.CurrentPrincipal to an authenticated Principal object and use the
CLR's Rules-Based security on your methods (declarative) or in the code
(imperative) for user/role checking.

Myself, I would just use SAM/AD as you can leverage all the tools already
built that staff already knows. Now you have a loosely coupled web service
that can be called locally or via the INET (if you so choose) that is
secured using the WS-* standards. And it is message based security, not
point-to-point security, so you can route messages with security intact and
save them, etc. Indigo will make all this even easier, but for now, WSE 2.0
is pretty sweet IMHO. They also have examples of caching SCT tokens in a DB
for web farm apps, so this sounds like a good fit for your needs.

Get SCT using RSA (no cert).
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Nick" <nt********@online.nospam> wrote in message
news:80**********************************@microsof t.com...

I am working on an application for a client that will involve using
remoting.
They do not want to use integrated security so I was going to store
usernames and hashed passwords in a SQL Database. I have a table in the
database that will also contain their session information which it will
encrypt and store as a class on the client end. Each time they connect to
the server I will pass the session class back and it will decrypt, then
validate it...similar to FormsAuthenticaion in ASP.net. The reason for
storing the session info in the DB is that the client may cluster the
remoted
component in the future and i would like to prepair for that. I will
have a
validation class that my remoted objects will tie into which will have a
ValidateUser method as well as a InRole method to check for permissions.
Being that the server(s) running the remoted components will be the only
items exposed and not the database the only way data can be accessed is
via
the remoted objects. My question is there a recommended way of using
remoting
with usernames and passwords stored in the SQL Database better than what I
am
doing or is my way pretty secure? I would love to hear any ideas that you
may have and am open to any suggestions that could make for a more secure
product.

Thanks in advance...

[William Stacey [MVP]]

When you install the WSE 2.0
http://msdn.microsoft.com/webservices/building/wse/ they have many examples
in the docs and in the samples dir. *framework.webservices.enhancements ng
would be another place to go. If that does not help, I may have a simple
example somewhere I could post. Ask on the wse ng and I could post there,
but someone will probably post first. Cheers.

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Nick" <nt********@online.nospam> wrote in message
news:5F**********************************@microsof t.com...

Do you know of any articles and / resources that talk about how to
implement
the CustomTokens as well as using custom principals to work with the
passwords stored in SQL.

"William Stacey [MVP]" wrote:

Your needs may dictate otherwise, but much of all this can be had today
with
WSE and using one of the security token types (UserName, SCT, Kerberos,
etc)
and the local SAM or AD. This is about the 4th post I have seen today
with
folks wanting to use SQL to store usernames/passwords. I am just curious
if
people don't know they can leverage the windows account DB or if they
think
that is an issue somehow? Anyway, if you go the WSE route, you can
secure
all method calls by requiring a UserName token or a SecurityContextToken.
A
SCT is more secure, but does require a server cert or you can use my
method
below using just an RSA key pair generated for your app (i.e. the one you
strong-name-sign your assem with will work great.) WSE will
automatically
validate the sent token against windows or you can override the
validation
yourself using Win32 LogonUser api or custom DB. You could also set the
Thread.CurrentPrincipal to an authenticated Principal object and use the
CLR's Rules-Based security on your methods (declarative) or in the code
(imperative) for user/role checking.

Myself, I would just use SAM/AD as you can leverage all the tools already
built that staff already knows. Now you have a loosely coupled web
service
that can be called locally or via the INET (if you so choose) that is
secured using the WS-* standards. And it is message based security, not
point-to-point security, so you can route messages with security intact
and
save them, etc. Indigo will make all this even easier, but for now, WSE
2.0
is pretty sweet IMHO. They also have examples of caching SCT tokens in a
DB
for web farm apps, so this sounds like a good fit for your needs.

Get SCT using RSA (no cert).
http://spaces.msn.com/members/staceyw/Blog/cns!1pnsZpX0fPvDxLKC6rAAhLsQ!303.entry

--
William Stacey, MVP
http://mvp.support.microsoft.com

"Nick" <nt********@online.nospam> wrote in message
news:80**********************************@microsof t.com...

>I am working on an application for a client that will involve using
>remoting.
> They do not want to use integrated security so I was going to store
> usernames and hashed passwords in a SQL Database. I have a table in
> the
> database that will also contain their session information which it will
> encrypt and store as a class on the client end. Each time they connect
> to
> the server I will pass the session class back and it will decrypt, then
> validate it...similar to FormsAuthenticaion in ASP.net. The reason for
> storing the session info in the DB is that the client may cluster the
> remoted
> component in the future and i would like to prepair for that. I will
> have a
> validation class that my remoted objects will tie into which will have
> a
> ValidateUser method as well as a InRole method to check for
> permissions.
> Being that the server(s) running the remoted components will be the
> only
> items exposed and not the database the only way data can be accessed is
> via
> the remoted objects. My question is there a recommended way of using
> remoting
> with usernames and passwords stored in the SQL Database better than
> what I
> am
> doing or is my way pretty secure? I would love to hear any ideas that
> you
> may have and am open to any suggestions that could make for a more
> secure
> product.
>
> Thanks in advance...

[Steven Cheng[MSFT]]

Hi Nick,

Have you got any further ideas on this or have you also had a chance to
have a look at my former reply. Anway, please feel free to post here if
there're anything else we can assist.

Thanks,

Regards,

Steven Cheng
Microsoft Online Support

Get Secure! www.microsoft.com/security
(This posting is provided "AS IS", with no warranties, and confers no
rights.)