1 / 8

Some Ideas about Approach to Cloud Authentication

Some Ideas about Approach to Cloud Authentication . Comments on the Entitlement Ontology Draft Presented by Radu Marian. Proposed by: Michael Poulin 22 Jan, 2013. Core Questions.

rollo
Download Presentation

Some Ideas about Approach to Cloud Authentication

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Some Ideas about Approach to Cloud Authentication Comments on the Entitlement Ontology Draft Presented by Radu Marian Proposed by: Michael Poulin 22 Jan, 2013

  2. Core Questions • Why CloudAuthZ needs to create new ontology for Authorization Solution for Cloud Computing instead of reusing known ontologies like RBAC and/or Rule-based one? • Elements of Entitlement Ontology depend on definitions of Execution Context and Business Cases, especially Client’s Business Cases (needs). Do they not? • Defining Authorization Solution for Cloud Computing and related Entitlement, we need a clear separation of areas constituted by questions: WHAT, WHY, WHO, WHERE, WHEN and only then – HOW. Do we not?

  3. Positioning of an Entitlement Solution, concepts of Business Cased and Client All presented terms are candidates for Ontology

  4. Entitlement Execution Context All presented terms are candidates for Ontology

  5. Entitlement Solution Model All presented terms are candidates for Ontology

  6. Comments on the Entitlement Ontology Draft Presented by Radu Marian, part 1 • Entire Entitlement Ontology better be expressed in business rather than IT terms. For example, an Actor may have its attributes like Name, ID, Title, etc. combined into Identifier for technology solution purposes but cannot substitute term ‘Actor’ in the ontology definitions (IMO). • Presented diagram does not distinguish between Entitlement per se and its environment. The letter is not a part of Entitlement Solution but is and acts an external influencer. • Term ‘Identifier’ is supposed to identify something. What does it identify in the presented diagram? IMO, we have to define an entry in the Entitlement Solution, which may have an identifier. This entry can be comprised elements defined in RBAC Semantic such as Actor, Permissions, Resources. • An Actor may be a stand-alone or belong to a Group (which is easy for on-boarding but extremely complex for administration/changing of individual rights of the Actor). A Resource should be a tangible or intangible entity (e.g. intangible entity is personal financial figures of a citizen of Singapore).

  7. Comments on the Entitlement Ontology Draft Presented by Radu Marian, part 2 5. A notion of ‘Risk’ may be an attribute of an Entitlement entry, i.e. a risk of particular Actor has certain Permissions to given Resource, but I suspect that an administration (estimate, re-estimate and update) of this attribute will be too complex for proper maintenance. 6. I believe that the business task that has led to creation/existence of particular Entitlement entry does not belong to the Entitlement Solution being an external influencing factor. Moreover, the task can change while the solution sustains and vice verse. However, such a task may be an information attribute of an Entitlement entry linked to the external documentation of the task (in architectural documentation). The letter means that all details of this documentation are hidden from the Entitlement Solution behind that information attribute. 7. IMO, a notion of ‘Context’ of an entitlement-based action includes a lot more than Time, particularly, business policies and regulations as well as technical platforms and interaction means, but does not include location. The letter may be an attribute of an Actor or Resource, not an entitlement-based action 8. IMO, having a Resource Group raises a risk of unauthorized access significantly while it is very convenient for on-boarding. Reason: a Resource Group is not aware and does not provide any information about who has access to it and an act of adding a new Resource into the Group (or removing a Resource) requires a meticulous verification of all Actors.

  8. Comments on the Entitlement Ontology Draft Presented by Radu Marian, part 3 9. A “Task” semantically cannot be a Capability, which is an ability to deliver certain result; a task delivers nothing. 10. How ‘RiskScore’ is meant to be used? Does it change access rights? May an Actor have different RiskScores for different access rights to the same Resource, to different Resources? 11. I am afraid that dependency of an Entitlement entry on risks or business processes is next to unmanageable for large companies with multiple documents, systems, applications and Cloud Providers. As we know, companies have a hierarchy of business processes where super-processes can change regardless of terms of the sub-processes, i.e. business execution context at the level of business process, business process area and Cloud Providers does not necessary cascaded down to the Entitlement Solution. This tells me that that business process and all related entities should not be a part of an Entitlement Solution but the other way around.

More Related