Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Section 3.1.3 - Controller - Authorization #26

Open
jimsch opened this issue Jul 8, 2015 · 4 comments
Open

Section 3.1.3 - Controller - Authorization #26

jimsch opened this issue Jul 8, 2015 · 4 comments

Comments

@jimsch
Copy link
Contributor

jimsch commented Jul 8, 2015

version -03

The bullet list does not seem to be specific to authorization as stated. It would seem that this is really a new paragraph two to justify having a controller component.

One of the things that is not mentioned here, but I don't know how to deal with it is the requirement that consumers must do something when they receive data. That I think falls under this bullet. (Requirement ARCH-007).

@ncamwing
Copy link

I don't see a bullet list for authorization (but some for authentication?).....

What do you mean by "consumers must do something when they receive data"? Do you mean akin to an "ack"?

@jimsch
Copy link
Contributor Author

jimsch commented Jul 21, 2015

Yes - I got it backwards - the bullet list is under authentication. I still think that comment follows.

Look at ARCH-007 as an example of consumer requirements.

@llorenzin
Copy link

Nancy to provide suggested text
Controller aspects are now addressed in 5.1
Lisa - make it more clear that consumers/providers are participants in authentication
Nancy - intent is to force consumers/providers to authenticate to controller
Controller provides the access to the SACM ecosystem (deployment specific)
Henk - control plane functions may be complimentary - authenticating party and authenticator
Has to be a supplicant providing what's needed to be authenticated
May be true of multiple or even all control plane functions

@ncamwing
Copy link

ncamwing commented Oct 9, 2015

Ah, I think all the components have to deal with some level of authorization (of the data). Here's a proposed new paragraph to describe authorization:

The restriction of Posture Assessment Information sharing
between the Consumers and Providers. At minimum, a management function must
define
the necessary policies to control what Providers can publish and Consumers to accept. The Controller is the authority for the type of Posture Information that a Provider can publish and a Consumer can accept. If a Controller is a Broker, then it may only grant authorization to the capabilities requested by the Provider or Consumer. When acting as a Proxy, as part of its authorization, the Controller may further obscure or block information being shared by a Provider as it distributes it to a Consumer. Similarly, a Repository may block information as recieved by the Provider and pass to the Consumer and to its storage the resulting authorized information.

Comments?

  • Nancy

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants