[Auth]Re: [DotGNU]Authorization and Security

[Mario D . Santana]

I'm cross-posting to the auth list, maybe we should move this  
conversation there?

In the last meeting on July 19, 2003, 1600UTC, I agreed to answer  
Mike's very thorough posting on DotGNU Authorization and Security with  
information on how MACS can meet DotGNU's identity needs.  I've tried  
to be as thorough in my response, so beware.

First, some context.  MACS is the Modular Access Control System.  It's  
a GPL'd Identity Management System with features on a par with Waveset  
Lighthouse, but with what we think is a superior architecture and the  
proven boon of being Free.  Medley Software Corporation (ie, the main  
MACS developers) hope to make money selling deployment, maintenance,  
etc. around a version of MACS branded Medley Conductor.  We've released  
0.7.2, and are working extremely hard on getting 0.8 out the door by  
the end of the month (we'd like to show it off at LinuxWorld in early  
August.)  0.8 will the the first beta-tagged release, since it will  
represent a core feature freeze.  (Because MACS is so extensible, this  
will be more like a mild feature chill.)

Being as how I'm a main developer of MACS, I'll certainly be biased  
towards it.  But I honestly think DotGNU can gain a keen edge by using  
MACS for its identity management needs -- a set of features which the  
competition (including MS!) are still struggling with.  An early jump  
ahead!  I think a full explanation of MACS is out of scope here, but  
suffice to say that apart from having built-in authentication,  
authorization and user/resource profiling capabilities, MACS lets you  
fold in identity information from scattered data stores across the  
network.  For more, see http://macs.sf.net

The only reasonable way to use MACS today is via its client API.  This  
is a C library with existing wrappers for Perl and Java, with more to  
come thanks to SWIG.  This means that there has to be a MACS server  
running somewhere for the C library to talk to.  However, there has  
been talk of making the MACS services entirely embeddable, and some  
work has already begun in that direction.  On the other hand, we have  
been talking about porting the MACS services to a different language  
(they're in Perl now) and if DotGNU can provide the functionality it  
needs, C# may be as good a language as any.  Maybe we can piggyback on  
pnet for general-purpose embeddability.

So the basic idea is to proceed in two phases.  First, C#, PHP, Python  
and Ruby wrappers for the C API, and calling that API from parts of  
DotGNU that are identity-aware.  This will bring the power of MACS to  
all these applications, allowing them to use identity information in a  
controlled manner from every data source available to MACS.

I should say that I know little about the DGEE and pnet.  I definitely  
won't pretend that I know how to, eg, protect webservices from one  
another inside the DGEE.  However, I have some general ideas about  
identity APIs from the last 3 years' work on MACS.  I'll try not to  
assume anything below, but if I make an egregious error, please ignore  
it.  ;-)

OK, on to the responses.

On Tuesday, July 15, 2003, at 07:08 AM, Mike Peters wrote:
> 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.

This sounds like a sandbox type of thing.  I don't know much about the  
details of VM security algorithms, but I assume it's got to be a sort  
of trap that only allows permissible operations.  That trap can call  
the MACS API to check permissions allow/deny the operation in a  
configurable manner.

> 2. Protect the webservices we are running and their data from programs
> running outside the execution environment.

This sounds like a firewall type of thing.  Perhaps all incoming data  
will be screened by the firewall procedure, which, again, can let the  
MACS API do the heavy lifting.

> 3. Protect webservice Foo and its data from webservice Bar and its
> users.

In my ignorance this sounds like a process similar to #2, but on a  
different boundary.  MACS might fit similarly into here.

> 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.

This makes good sense.  A flexible, extensible API like MACS' provides  
just such a framework, while allowing Foo to choose whichever available  
API suits her.  This would be as easy as making sure the proper API is  
available from the framework (possibly the API would itself be exposed  
as a webservice.)

The System.Security namespace provides a somewhat generic interface to  
this sort of functionality, as well.  In implementing parts of  
System.Security, DotGNU might be well served by having the ability to  
choose between several security models, one of which might be the MACS  
model, using its API.  A cursory search on msdn reveals nothing of the  
sort in the "standard," so there may need to be a way to configure this  
outside of code, preferably per application or webservice.

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

MACS is extremely verbose.  0.8 will have a more structured audit log  
and viewer.  There are also sophisticated real time log analysis and  
reporting tools planned for the not-too-distant future.  So for the  
DGEE, using MACS would take care of this.  For individual applications,  
this is a thing for the individual developers to consider -- by  
choosing MACS, their applications get the same benefits as the DGEE.   
And for System.Security, the MACS model would perform all its auditing  
as a side-effect.

> I believe in order to clearly define a workable security policy for
> DotGNU we need to agree upon adapting or adopting a standard  
> vocabulary.
> [...]
> 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/ )

This is a great idea, but I doubt anyone will have time to memorize  
that document in one go.  We might make it established practise for  
dg-auth-wg to refer to these documents in arbitrating confusions, but a  
glance through the documents tells me these definition are usually  
fairly well understood in casual usage.  If we're going to write a  
complete, formal specification, then we'll definitely need this, but  
that's a very large task...

> [...] 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
> ).

I think we'll all agree to this.  Below I outline how MACS can "cope"  
with these scenarios.

> In brief those scenarios are:
>
> 1. Direct trust by username/password - the simplest, best known and
> easiest to defeat.

This is supported at this time, with no modification.  The back-end  
process to verify the username/password combination is easily  
extensible and configurable.

> 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.

This operates similarly to username/password, without the username  
part.  The back-end process simply ignores the username and creates a  
session based solely on the password (token.)

> 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.

Similar to scenario 2, the back-end process simply verifies the given  
token against the token server (which may itself be MACS.)

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

This is always the case -- however, the MACS token (session key) can be  
ignored if there will be no need for it later.

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

MACS would probably not perform this processing directly; however, a  
firewall procedure can certainly use MACS do, as I say, do the heavy  
lifting.

> 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.

MACS incorporates group- or role-based as well as profile- and (soon!)  
session-based access controls.  The group memberships, role  
assignments, and profile and session rules controlling access to  
resources are administered via the MACS UI at the moment.  However,  
MACS will soon have a Resource Management Service included in the API,  
to perform these operations programmatically.

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

MACS achieves this with its fine-grained permission features.  Access  
controls can be set at the profile item level, protecting user details  
from unauthorized access.  I should mention that FrePort was a scheme  
to protect user information by encrypting it.  MACS does not support  
this directly, but for a given secure/encrypted data store, a back-end  
method adapter would immediately lend MACS its capability.

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

MACS has been in production at a very large, unnamed software company  
for 3+ years, protecting extranets and intranets.  It can do web  
clients.  =)

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

Depending on the exact "solution" MACS may handle these scenarios  
directly, or an initial exchange point may leverage MACS to perform its  
duties.

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

This is what MACS was designed for.  However, support for the emerging  
standards needs to develop before I'm willing to call this  
functionality complete.  Still, MACS can log in users based on their  
Yahoo! or ESPN.com password at this time, and new method adapters are  
easy to write.  That's 50% of what the world means by "Federation"  
right there.  All that's left is to make the federation process general  
and invisible by supporting the standards.

> 11. External validation services.

Yes. =)

> 12. Delegation.

Again, yes.  The entire MACS administration scheme is centered around  
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.

Precisely.  MACS is a service provider -- consumers of this service use  
it at their pleasure.

> 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

Something like the configurable System.Security models idea would  
provide this even for applications which were written against a single,  
inflexible API.  Developers who wish to use MACS simply call the MACS  
API or webservice.

>  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.

I agree, and I think everyone else does.  AFAIK, these boundary  
protections are part of the DGEE's job?

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

These WS-* standards are the standards I was talking about above, in  
context of support for federation.  Other standards include SAML,  
XACML, S2ML and AuthXML.

> 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. [...]

After clearing this up with Mike (melzo on irc,) my response is that I  
think the DGEE's auth should be a component-specific implementation of  
the general DotGNU auth policy, designed to interoperate with other  
DotGNU components.  I have no idea what a the general DotGNU auth  
policy should look like, though.  :-/

This general policy might be an excellent topic for another thread.

> [...] 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.

Great!  I've been keeping my head down, as well, turning MACS into  
something I can be proud of.  Now that the core framework is almost in  
place, that should be any day now.  After 0.8 our number one priority  
will be to develop a roadmap for 0.9.  DotGNU's needs should play an  
important role in that.  (Although hopefully we'll have real paying  
customers to appease as well. =)

Congratulations on your reading stamina if you've made it this far. ;-)  
 Thanks for the conversation, and cheers!

mds