Implement Authentication and Authorization for access to different Taxii services

[ScottyAU]

A requirement for us as an organisation, and I would hope most people developing currently a Taxii capability, is Authentication and Authorization to control who get's access to what Taxii services you are intending to provide.

I'm thinking application level username/password with associated permissioning via groups for each instance of each service.

Example:

Inbox service
-- instance 1
-- instance 2
Poll Service
-- instance 1
-- instance 2
Collection Management Service
-- instance 1
-- instance2

UserA get's access to "instance 1" on all services
UserB get's access to "instance 2" on a only the Poll service

This would allow full control of who can see what data contained in each data collection, as well as who can push data into which data collections.

This would allow Circles of Trust to be provided by Taxii, to meet an individual organisations needs around how they wish to segregate the users in their Taxii environments (some may not require any segregation).

I'll need to go back and read the spec to see if it is discussed - but currently I would envisage that the Discovery service has the ability to essentially reflect the users groups - in that when they hit the Discovery service endpoint they get back a list of the services that they have access to - not all the services that are offered. (Could be turned on or off to meet organisational requirements).

I was hoping to get some feedback on this before exploring any potential implementation options.

[MarkDavidson]

Purposefully, The TAXII Specifications do not specify Authentication and Authorization beyond the concept of "It's your software, do something that you think makes sense". This is because when writing TAXII, we took the approach of attempting to identify the bare minimum that information sharing software would need for successful exchanges.

In terms of YETI/django-taxii-services, which are software, need to do something that we all think makes sense (I'm dangerously close to circular rhetoric at this point!).

I haven't given much thought to this idea yet, but I agree it's something that needs to be tackled. Maybe it's worth starting out with a requirements discussion as an attempt to scope the work? My gut reaction is these are good candidates for requirements:

• The "built-in" authentication/authorization system should be functional enough to be used on it's own, but it doesn't have to be fully featured (maybe a simple RBAC solution works)
• The "built-in" authentication/authorization should be connectable to well known/commonly used authentication repos (LDAP comes to mind).
• The "built-in" auth system should support TLS Mutual Auth (It's my personal opinion that secured TAXII systems should be using at least TLS Mutual Auth, if not multiple auth factors)
  • Of course, this opens a huge can of worms in terms of certificate management, user provisioning, etc.

As I type this, I'm realizing that I'm approaching boil-the-ocean territory with scope. So maybe this is the "desired" state, but django-taxii-services starts with something much smaller.

I guess I'll also pose a simpler question - would a basic RBAC (Role based access control) authentication/authorization system be sufficient for your needs?

[gtback]

Does it make sense to tie django-taxii-services in to using Django's auth system? Or at least a method of managing permissions of django users and what TAXII content they can access?

[ScottyAU]

Thanks Mark.

Initally just doing some basic RBAC that can be tied into the different TAXII services would more than meet our needs.

The only bit where I think where not having anything more specifc in the standard itself might (and I say might) be an issue is the discovery service. Having the response to a discovery request tied into a users access makes sense to me - ie you only see what you have access to and not everything that is available.

I'd be interested in peoples thoughts around whether this is something that is required/ should be specificed - or just left to the software/implmentation to decide/implment. The advantage I can see is making sure all implmentations have this capability. Maybe it's not a hard requirement though - just an optional extra that we'd make use of.

Longer term I would 100% agree with the two way/client based TLS as well another layer (user auth or otherwise). Short term though this can be easily done in front of a Yeti instance though - adding layers which is always a good thing.

[MarkDavidson]

@itchycube,

I think what you're looking for might already be in the spec. Here's an excerpt from Section 2.1.1 of the TAXII Services Spec [1].

A Discovery Service is not required to disclose all TAXII Services of which it is aware; a
Discovery Service can use a variety of factors to determine which Services to disclose to the requester, including but not limited to the requester's identity.

A tenet of TAXII is that the implementer has control over information sharing and that TAXII does not indicate any kind of access level.

To comment further, I have a slight inclination that TAXII should be a tad more "discoverable" (in the same way email servers and web servers are discoverable via DNS), and I'd like for a single well defined entry point (even if deployments are allowed to stonewall and say "nothing to see here").

Either way, I like where @gtback is at for a starting point.

Thank you.
-Mark

[1] http://taxii.mitre.org/specifications/version1.1/TAXII_Services_Specification.pdf

[ScottyAU]

Thanks Mark - that bit of the Spec looks like exactly what I was thinking.

Agree on the starting point - will see how I go getting some time :)