Groups vs Roles.  What ever the difference, I think these should slice the universe of users differently.  If groups are based on you are in the organization (a partitioning strategy that can partition everyone), then roles should partition everyone by some other measure, say occupation. 

Another strategy is to assume that the groups are made up by an external organization and are too granular for your purposes.

The final strategy is to have groups == roles.  For each group create one role.  This removes groups from the policy altogether.

Task. Task are tricky.  If you want to give someone the right to send email, update a database and delete a row, but not the right to do any of those individually, then *don’t* use a task.  A task means that if some one is able to do one of the operations *individually*, it logically follows that they can do them all.  For example, “delete own account”, “delete other accounts”, “delete lapsed accounts”, “delete active account” might be put in a single task.  Then you grant the task to a high level user and save yourself four role associations (over using strictly operations).

If you do want the user to complete a series of actions as a whole, but not individually (for example, he can send email to himself as part of a purchase transaction, but not directly call the email method with arbitrary recipients) then the purchase should be an operation.

And now I’m too tired to keep thinking. Good night folks.  [Hey this is an un-edited blog, what'd you think you'd stumbled into? PC Magazine?]

So I’m buying an SSL certificate. To prevent getting a MSIE7 error, it needs only be unexpired, match the URL and come from a ‘trusted authority’.

A trusted authority, like rapidssl.com will give an SSL certificate to anyone who “controls their domain”

Why don’t we just call a spade a spade and tell people that an SSL certificate is a means of encryption on the wire amongst unauthenticated parties?

I got a magazine subscription from an online company that did everything possible to hide their identity (anonymous domain, no physical address)– and they used SSL. I did get my magazine subscription, so it appears that I was buying from a company that want to stay anonymous, maybe for tax reasons. The transaction size was small and the website was plausible, so I wasn’t exactly sending a check to Nigeria. All I really need for this transaction is *correlation* I can now correlate my experience with the first time I interacted with this anonymous company with the second time I interact with them and form a sense of their reputation. In fact, if a reputation server was what stood behind the URL & SSL cert instead of a picture of a guy with a bag over his head, ecommerce would be a lot safer.

I really don’t see the value in the expensive SSL certs either. To get the additional trust from that cert, users have to:

1. Understand that you $1000 cert underwent a rigorous audit, unlike the vast majority of certs.

2. Know how to click through to see the subject on the cert

3. etc.

Imho, SSL is not authentication at all. It’s more like meeting a stranger on the street and agreeing to speak in Esperanto so that the other strangers on the street can’t understand you.

The URL is not an identity either. OpenId is proposing that if you control an URL, you are that URL. But URL’s lapse all the time. Even excluding the rather rare, but technically possible hijacking of DNS servers and domain names, if my URL lapses, someone could pick it up and pretend that they were Matthew Martin. They wouldn’t be as stylish and suave, but an average web browser would be hard pressed to know the difference.

Application Rules

If MyApplicationLogic.CheckNonRoleInfo() then
            AzMan.CheckAcces(...)
end if

This above CheckNonRoleInfo() method has limited access to the AzMan algorithm, which searches the entire role data structure for evidence that so & so is allowed to do something. It would also be plausible that something depends on role and non-role information, so it’s possible CheckNonRoleInfo() might evolve into CheckNonRoleInfo(CurrentUser, UsersRoles(), TimeOfDate, OtherRelevantFactor). Now this method is probably implementing some of the same logic as AzMan.

AzMan Rules

AzMan.CheckAccess(..., MiniDBOfNonRoleInfo())

The hooks are in the CheckAccess engine, so it combines both Role & NonRoleInfo in a check.

The BizRule pattern means the rule is part of the AzMan Algorithm, which searches the entire role data structure for evidence that so & so is allowed to do something. I’m imagining that the AzMan role engine hold the roles as some sort of network or graph, which it traverses. Everytime it gets to a node with a Rule attached, it evaluates that rule in addition to normal role checking logic.

SQL Style
You can call a method (stored procedure) that access resources (views and tables) on your behalf, but you can’t always access the resources directly. SQL Procedures almost analogous to AzMan task, and tables are analogous to operations. How ever, an AzMan task implies you have access to all the components of the task directly as well as through the task.

AzMan Style
If you can call any method (task) that uses a resource, you can use that resource directly.

Both styles, make sense, why doesn’t AzMan support them both? Well, in a sense, you could simulate SQL style by making all stored procedures ‘operations’ I think the only disadvantage is that if there is an action, say sending an email, which is implicitly available in one operation, but not another, it might be confusing. For example, if you have a task called, ‘contact customer’, which is make up of ‘lookup address’, ’send email’– you might decide to change ‘contact customer’ to an operation, since you don’t want the user to ’send email’ except in the context of the ‘contact customer’ task.

Ok, I see the intent of BizRules in AzMan. Sometimes the question, “Are you allowed to do this?” depends on more than your level of training (group), your profession (role), place in the organization (group), the task in question, or the operations that make up the task. Sometimes it depends on something like, the time of day, how much money you’re talking about, and so on.

So in AzMan’s 9 parameter CheckAccess() method, methods 4 and 5 allow you to pass in some value-parameter pairs. The business rules are attached to roles and tasks. Now since CheckAccess doesn’t let you pass in the name of a task or role, it must be starting with the operations and works backwards. If it hits a role or task with a BizRule attached to it, it runs it.

The script’s environment gets a global object AzBizRuleContext, which has the method GetParameter(stringName) and the Boolean property BusinessRuleResult.

Try as I might, the only way I could get my BizRule to talk to me was via the AzBizRuleContext and FSO. MsgBox didn’t work.

Having invested some time into learning how this feature works, here is my critique.

1. The invocation is too weird. It looks like all parameters go into a great big pool and are used by any rules that happened to get invoked while going through all the relevant roles and tasks. This creates an opportunity for parameter name collision, wild behavior if these are using values by reference and if these rules can modify the parameter values. (A test for another day to see if these are the case)
2. Since you can use CreateObject(progId), you should create COM wrappers around your .NET code and invoke it that way.
3. The usage of parameters 6 through 9 appear to be for callbacks (maybe a sort of output parameters? A way to call the code of the caller?) Either way, I’m not sold on these patterns. If a pattern is inexplicable, undocumented—it is an anti-pattern.
4. You can invoke business rules in any type safe way. In fact, it doesn’t look like the developer can invoke any rule. If the AzMan store doesn’t think the rule applies, the rule isn’t applied.
5. Also, in Azman, you might get the right to an operation via many paths, biz rules might get applied when you weren’t expecting them. This sounds like it would lead to defensive programming, where you try to pass in all the parameters for all the biz rules in the entire store, all the time. Ugh.

Here is an alternative:

If MyBizRules.CheckRule(Amount,TimeOfDay,MoodOfAdministrator) Then
    AzManStore.CheckAccess(p1,p2,p3,[p4,p5,p6,p7,p8,p9]) ' p4 through p9 are nothing
End If

Application developers understand Amount, TimeOfDay, MoodOfAdministrator in a way that an API dedicated to groups, roles, tasks, and operations can’t. These are also domain specific issues. The point of checking is unambiguous. You won’t get a BizRule checks just because there were 15 ways to link the user to a particular operation and four of them crossed BizRules you weren’t thinking about. (Conversely, when you write a bizrule, you don’t have to forecast how many way an access check might shake out and think if they semanticly make sense in each case)

Update: Further thinking on this makes me think that the names/values arrays actually represent the universal relationship pattern. This is the idea that all data structures could be represented by a two column table with the name of the data entity and it’s value. This scales to a handful of data entitities. Anymore than that and you have a custom databases that is impossible to parse, search or use without an enormous amount of code.

[This article is looking at authorization design from an AzMan standpoint, with AzMan jargon]

Users are atomic users. Operations are atomic securables, either actions or resources (the right to DO something or the right to do something TO something).

Groups can be any combination of all the users, so when designing groups, you have combinations, so k!/(2-k)!k! two user groups to consider, K!/(3-k)!K! three user groups to consider and so on. Of course there is only one ‘everyone’ group. That is a lot of groups. Let’s invent some theory to decide how to create the groups that make sense.

Natural Social Groups. Just ape the social groups that appear on the business organization chart. That chart was meant for controlling chains of command, and may or may not make sense in the context of a petty cash tracking application. Natural social groups have the advantage of being well known, fairly easy to update without much application knowledge.

Risk Driven Grouping. We check access to prevent certain users from doing things. Who do we really want to prevent from doing things? People who could do harm, either by being indiscrete with the information they learn, or by destroying data by deletion or update. By this line of reasoning, you could group people by

auditability—eg. Anonymous users versus authenticated users

seniority—more experienced users, users that have completed training can safely get access to more functions

trustworthiness—our own staff is likely to be more loyal and concerned about our data then business partners who work for another organization

legal status—There may be formal groupings, such as a security clearance.

Application driven groups. Let’s say not all supervisors can manage petty cash, and the business organization chart doesn’t have a ‘Petty Cash Managers’ group, so we create a group with the 14 people who can manage petty cash—it might have natural group of sales managers plus all the managers except the engineering department. We will want to create a role.

Roles are idealized work descriptions—or groups of task depending on how you look at it.

Tasks are groups of operations, operations being the atomic securables. A risk driven grouping of tasks would separate securable actions into those that are potentially destructive vs those that are not, for example, update and delete are destructive, create is less destructive and read is a threat to secrecy, but not data integrity.

The Check

AuditIdentifier, InternalScopes Array, OperationIds Array

The store holds multiple applications. Presumably the applications map to real world applications. Scopes are like sub-applications. Operations are the atomic securable units.

The parameters are arrays so that you could potentially check a large number of securables, say the editability of 50 properties in a single call.

Interestingly, if you are using tasks to group operations, at time of check the application still has to enumerate the Operations, you can’t call

AccessCheck(”access denied”, null, PurchaseTask, ….

I suppose it is possible to query the store for what operations are in the PurchaseTask, but I don’t know how yet.

BizRule Parameters

The next 5 paramters have to do with the Biz Rule Parameters. If anyone had asked me, I would have used a pattern like:

dim br as BizRule(…)
br.setParams = [some dictionary]
accessCheck(error, scope, task, br)

But no, that isn’t built in.

A check that depends on more than just the roles
BizRule param names, BizRule Param values

I would question the wisdom of putting business logic into an authentication store, but it might be okay if you are using a data fortress strategy (where business rule checks are put into multiple tiers because you are in an organization with a complex application that is composed of many tiers that might be controlled by different organizations with different business rules)

A BizRule check that needs to do a call back
Com interface names, Com interface Flags, Com interface values

If the BizRule needs to talk to a resouce that you can’t provide in the parameters, thenyou have to provide a mechanism for callbacks to the calling code.

1. You don’t have to write your own authorization scheme. (But you don’t get much choice either, Azman works best if you are writing an intranet application, running on XP or Windows 2000 or 2003 using windows authentication.)

[Update, it seems you can implement "custom principles" which seems like a way to use AzMan with something other than windows authentication. The trick is to make up your own SID's.]

2. Freedom from the IT gnomes up the hall. You don’t have to ask your domain admin to create and maintain groups for you (or convince him to delegate the task to you).

3. Freedom from Active Directory. You don’t have to install your own subdomain controller or ADAM instance. (Unless you enjoy the pain of ADSI scripts, then by all means do so. Write it in assembler, too and sit in on a bed of nails while your at it, and chew broken glass.)

4. Granular security without the extra work. Through the use of tasks, nested groups you can fight degenerate role based security (where everyone over time becomes a member of all groups) and the decision explosion (where fine grained security leads to a explosion in the number of access granting decisions an administror must make)

5. Centralize RBAC (role base authorization checks). You can make access checks dependent on more than just role membership and store that code in the same place that you store your role data.

6. AzMan is for making access checks that are typical to a business application, not a computer network.

7. Open. The xml store is based on an open format. I suppose a java app could query the xml document directly. (And in longhorn, the store is in SQL tables)

8. Managed Code Accessible. AzMan works with .NET and ASP.NET. And in the case of ASP.NET, you can talk to AzMan through the ASP.NET 2.0 role manager API or the COM interop API.

9. Scalable. AzMan is designed to work with big applications. While I personally think that 90% of the time a scalable application is likely to be an over engineered one, it’s reassuring to know it can process thousands of authorizations per second (* see footnote on xml data stores)

10. If you say it fast, it sounds like, “ass man”

A few reasons why not

Significant learning curve. I think this is due to RBAC being a complex idea to start with.

It is COM. Have fun trying to make sure your objects really are disposed of.

It uses VBScript for BizRules. Untyped programming without intellisense, whee…I thought that was all behind me. [Although with some hoop jumping you can have the VBScript call .NET]

It uses xml as a database. Using any single file as a database is a recipe for inconsistency and deadlock. If you use XML, it would make sense to contrive a user group strategy that doesn’t require adding users to AzMan roles, i.e. if you could assign users to a windows group and then work only with windows groups in the xml file.  Why? So that you would never have to have users update the XML file.  But if you are using custom Auth, then you’ll have to update the file at least one per user creation.  As long as that isn’t happing every few seconds, you might be okay with XML as a database.

What if your application has only one human user? You’d think that you’d have to grant him the right to do all operations in the application. However, if the application has a learning curve, you might have several roles, such as beginner, intermediate, advanced, where the advance user can do operations that a beginner would be better off not attempting for fear of mistakes.

What if you have many users, but you are using a service account? (Sometimes called a trusted subsystem architecture) You can still use role based authentication to restrict access to new code. For example, if my application has method1(), method2() and method3(), developed in versions 1, 2, and 3 respectively, if I discover that there is a bug in method3, I can either do a roll back, (which may be hard to do, especially if you have done any database schema changes), or I could remove the service account from the Version3 role. To make this really work, I’d also have to intercept all the “access denied” messages and replace them with “not implemented” messages.

What if you have only a few users, say 5, or 2 or 1? At what point does the creation of roles, nesting roles and so on start to outweigh the reduction of user to securable decisions? Hard to say, that would require some math. At one user, it’s pretty clear that creating roles adds extra decisions.

However, users are unique and if they leave the company, we don’t want to have to reassign rights to a new user. If we granted rights to the JohnDoeGroup (population one Mr. John Doe), when John leaves the company, we can add Jane Doe to the group and not worry about having lost the potentially complicated set of role memberships and right granting that John Doe needed to do his job.

When creating an authorization store, make sure you are in Developer mode– Action menu, options, developer mode. Every time you open the azman console, it resets back to administrator mode.

The context menu changes for each node. Top node, you can create a new store, next node you can create an application, next node you can create a user group. These actions are not duplicated in the menu system, so if you were searching the menu’s, ha ha! Fooled you.

You can’t create two applications that differ only by version. So if you do have two applications running at the same time, you ahve to give them two names, like App1 and App2.

The “Role Definition Properties” page is some what non-intuitive. The Definition tab has two means:

- What the role can do

- What other roles the role is a member of

The difference between Groups and Roles is not clear. They appear to be the same concept, except Groups can be formed from an LDAP query and Roles appear to be strictly nested (i.e. they hold groups, but not individuals) Forcing all roles to nest by at least on level implies to me that there are going to be a lot of degenerate roles (that have exactly one group in them).

And finally it looks like AzMan can only talk to an Activite Directory, Local or Adam authentication store. This is quite a bummer if you were thinking of using AzMan on a hosted website where the account is likely to be running the application under a service account.

I think the one thing I don’t like about this user interface, is that there is nothing in the user interface to suggest what is a suitable operation, task, role or group. When I first started dinking around with the application, I kept wanting to so something like create a operations and tasks with the same name and to create roles and groups with same name. (or worse, confuse roles/groups with operations/tasks)

Another point of confusion I blame on the UI is the scope of the group depends on where it is in the tree. It would have be nice if there was a 2nd attribute on the tree to just state the scope rather than make me infer it from where it is.

Ok, exercise for the reader, rewrite the UI so that all operations can be performed using traceable powershell scripts.

Authorization Store, Application and Scope– A store holds applications, for which each is a complete set of groups, roles, tasks and operations. If your application is a two headed beast, say half store, half customer blogging engine, then you might want to keep separate your roles strategy for the store and the blog. Or you might want to set these up as two different applications. So far the only advantage I can see to having several scopes vs several applications is that you get an additional set of roles with a ’scope’ that extends over several azman scopes. Ugh, can’t we invent some new jargon instead of reusing jargon that already has well defined meanings?