OAuth is DAC. What do you do for MAC?
OAuth's design goal is to let end users grant applications access to their resources in the cloud. In other words, the underlying access control model is discretionary: it's my toy, so I decide who gets to play with it. A perfect fit for our brave new world of social media. Or is it?
Most corporations are not so happy to let individual users decide who can access data - they want centralised control and grant access according to a security policy. In other words, Mandatory Access Control, or MAC for short. It is mandatory in the sense that, whatever the people involved in creating the data think or do, access rules laid down in the policy will be enforced. Not only staid brick-and-mortar firms cling to such old-fashioned ideas.
Social media also has a need for MAC. Consider, for example Twitter, which uses OAuth to give users' control over their accounts. To Donald Trump's chagrin, a helpdesk worker suspended @realdonaldtrump in the fall of 2017. There had been no consent from the end user prior to the event. Presumably, the helpdesk worker acquired privileges to suspend accounts by virtue of his or her assigned role. That's a centrally administered policy, MAC in other words.
I often come across the need to combine Discretionary Access Control, or DAC, with MAC. OAuth authorization servers' support for DAC is enshrined in standards, whereas implementing MAC is often through ad-hoc extensions. This is ironic given MAC's reputation for high-assurance environments and the tradition of MAC models with sound theoretical foundations.
Given that OAuth and attendant specifications such as OIDC seem here to stay, I think it is important to find clean ways of reconciling them with MAC needs. I have been trying to do this in my projects but found little in the way of vision on the problem, let alone guidance for design and implementation. I hope to contribute to bridging this gap and will be pitching some ideas at a number of events. This week, for example, I will be presenting the problem at a seminar at the DistriNet Research Group and next week at the OAuth Security Workshop.
Let me know if you want to be part of the discussion.
Most corporations are not so happy to let individual users decide who can access data - they want centralised control and grant access according to a security policy. In other words, Mandatory Access Control, or MAC for short. It is mandatory in the sense that, whatever the people involved in creating the data think or do, access rules laid down in the policy will be enforced. Not only staid brick-and-mortar firms cling to such old-fashioned ideas.
Social media also has a need for MAC. Consider, for example Twitter, which uses OAuth to give users' control over their accounts. To Donald Trump's chagrin, a helpdesk worker suspended @realdonaldtrump in the fall of 2017. There had been no consent from the end user prior to the event. Presumably, the helpdesk worker acquired privileges to suspend accounts by virtue of his or her assigned role. That's a centrally administered policy, MAC in other words.
I often come across the need to combine Discretionary Access Control, or DAC, with MAC. OAuth authorization servers' support for DAC is enshrined in standards, whereas implementing MAC is often through ad-hoc extensions. This is ironic given MAC's reputation for high-assurance environments and the tradition of MAC models with sound theoretical foundations.
Given that OAuth and attendant specifications such as OIDC seem here to stay, I think it is important to find clean ways of reconciling them with MAC needs. I have been trying to do this in my projects but found little in the way of vision on the problem, let alone guidance for design and implementation. I hope to contribute to bridging this gap and will be pitching some ideas at a number of events. This week, for example, I will be presenting the problem at a seminar at the DistriNet Research Group and next week at the OAuth Security Workshop.
Let me know if you want to be part of the discussion.
Comments
Post a Comment