[DotGNU]Authorization and Security

[Mike Peters]

I missed the original thread 'How to Authorize?' somehow and only came
across it in the archives so I'm replying here in a fresh thread to the
whole thread at once.

> Peter Minten wrote:
>AFAIK there hasn't been much work on the authorization mechanisms in
>>DotGNU for the last year. With DGv1 approaching it seems to me that
>>it's important to have a clear view on this.

Agreed, but I think before we go into how to authorize, it is vital we
have a clear view of just what it is we are trying to protect. It is
important that, as a project we don't implicitly or explicitly claim to
protect data which it is not really our duty to. In other words we don't
want to be liable for any violation which occurs to webservice Foo which
is caused by carelessness/ignorance on the part of the developer of Foo.

In terms of DotGNU and Webservices what we need is to:
1. Protect data and programs outside of the webservices execution
environment from the webservices we are running.
2. Protect the webservices we are running and their data from programs
running outside the execution environment.
3. Protect webservice Foo and its data from webservice Bar and its
users.

Protecting Foo's data from Foo's users is the responsibility of whoever
develops and/or administrates Foo. DotGNU should provide a framework
which facilitates the development of secure webservices however the
burden of responsibility lies with the individual developer for how he
implements security in his webservice. In the same count we should not
impose a particular model upon the developer.

There should also be a system for auditing and logging connections and
usage.

I believe in order to clearly define a workable security policy for
DotGNU we need to agree upon adapting or adopting a standard vocabulary.
A security policy which is difficult to define in words will be
impossible to implement, besides, a standard vocabulary/glossary will
help in other areas too besides security. We don't need to write our own
vocab from scratch just inherit from rfc2828 (the Internet Security
Glossary) ( http://www.ietf.org/rfc/rfc2828.txt ) and/or the w3c Web
Services Glossary ( http://www.w3.org/TR/2002/WD-ws-gloss-20021114/ )
adding our own terms and/or overriding their terms where necessary.

Much work has been and is still being done, by the working party
consisting of IBM, Microsoft and Verisign, defining the particular needs
of webservice security based mainly on existing technologies. I believe
that with any security policy it is better to use the work of others
rather than to try and formulate some radical new strategy and as it has
already been said we don't need to reinvent the wheel. Besides users are
going to expect a comparable security model which enables end-to-end
security and allows developers to incorporate their existing security
models within our scheme. At the very least if DotGNU is to be a viable
option for application developers our model should be able to cope with
most of the scenarios outlined in Section4 of 'Security in a Web
Services World: A Proposed Architecture and Roadmap'
(
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnwssecur/html/securitywhitepaper.asp
).
In brief those scenarios are:

1. Direct trust by username/password - the simplest, best known and
easiest to defeat.

2. Direct trust by security token - the requester and service provider
agree on a security token which is then sent with the data and verified
by the service provider.

3. Security Token Acquisition - a reference to a security token and
proof of possession is passed with the message which is then verified
against a token on a token server by the service provider.

4. Issued Security Token - the requester provides proof of identity to a
token provider and acquires a token which he sends with the message.

5. Firewall Processing - incoming XML message headers are examined and
processed by a firewall according to the content.

6. Enforcing Business Policy - it should be possible to codify and
validate existing information security policies such as security levels,
interdepartmental relationships and other access controls.

7. Privacy - users privacy must be respected (and the legal minefield
that ensues).

8. Web clients - esp. browsers do weird and wonderful things and we
shouldn't be caught out by their downfalls.

9. Mobile Clients - cryptographic solutions suitable to the power of
mobile devices must be available as must secure gateways and proxies.

10. Security Federation - security federations between token and
identity providers.

11. External validation services.

12. Delegation.

Remember we only need provide the framework by which developers can
implement these schemes for their webservices rather than implement them
per se for webservices running on DotGNU, as such, some will take
minimal to no code to implement. Developers should be free to choose the
policy which best suits their application and not be limited to what
DotGNU developers (no matter how well intentioned) think is the best
scheme but they need to do this in the comfort that other services not
as well secured as their own will not affect them (see my outline above)
and as such some policies will be needed to be implemented internally. I
stress again the boundary between that which we are obliged to protect
and what we are not needs to be well defined.

We should also outline how we intend to deal with the different aspects
of the security specification, namely:

WS-Security
WS-Federation
WS-Trust
WS-Policy
WS-Privacy
WS-Authorization
WS-SecureConversation

It seems to me that the thread 'How to Authorize?' resulted from a
confusion as to whether the thread was discussing DotGNU authorization
or administrative authorization of the execution environment (ie the
DGEE) itself. If it was intended to be such I apologize, it seems I'm
the one who's confused ;) but we need to draw the distinction between
what is the overall security policy of DotGNU and the security of
individual applications within the DotGNU framework (eg the DGEE). The
discussion was generally applicable to the security of an application
but not to that of overall DotGNU policy (in my opinion of course).

Anyway, as someone who has dealt with security on a Network and web
application level as a developer and analyst/tester on and off for the
last 3-4 years that's my 2pennies worth (although I haven't dealt with
webservices as such). I was keeping my head down as regards active
involvement until at least mid-August as I'm currently extremely busy
with work and deadlines and I'm off on holiday in a couple of weeks and
so will only have limited computer access, but, as things seem to be
moving on the security front I'll crawl out of the woodwork and state
that I could (would like to) be of assistance in matters security but
please bear in mind my attendance may be erratic for a while.

Sorry if anything is unclear, this email is a bit rushed and I'm
surrounded by builders drilling stuff (why do they decide to do
refurbishments when I've got deadlines to meet?). Any questions you have
fire away and I'll try to answer in good time.
-- 
Mike (aka melzo)
Web Site: http://www.ice2o.com/
JabberID: address@hidden
Registered Linux User #247123

"A thousand years ago we thought the world was a bowl. Five hundred
years ago we knew it was a globe. Today we know it is flat and round
carried through space on the back of a turtle. Don't you wonder what
shape it will turn out to be tomorrow?" [Lord Vetinari] 
(The Truth)