Use Hierarchical Names to Your Advantage
Category Domino
I find that one of the more powerful, yet often under utilized, features of Notes/Domino is the hierarchical name scheme. For a long time my only development exposure to the Notes Name was something like this: @Name([cn];@Username) and every time I wrote a statement like that I swore my vengeance on the developer who added hierarchical names to the product.
Today, much more experienced and hopefully wiser, I use Notes Names to the fullest and am extremely happy the hierarchical naming exists in the product.
In my current organization we use an O and two OUs in ALL of our usernames (both Notes created client users (user.id type users) as well as web browser based Domino users.) I don't know if other organizations create hierarchical names for their nonNotes client users, but they should, as you will soon see. Obviously, you can structure the hierarchy however you need to, below is how we use it.
O The Organization Level
We have a single O (organization) value. We are leaving it alone for now because of future business expansion planning.
OU1 The Relationship Level
We have 6 OU1s. E = employee, A=agent, C=customer, V=vendor, I=shareholder, and S=server. Most of our ACLs have at least an entry like */E/Co (Co represents our company initials.) Whatever access is granted to that single entry is granted to ALL of our employees...with no grouping required (we block terminated employees from ever reaching the server with a Server Access control.)
OU2 The Workgroup/External Organization Level
At OU2 we either identify the workgroup of our employees (Andy Broyles/IS/E/Co) or the organization code of our agents, customers, and vendors (John Smith/AB01/A/Co, Sally Brown/DW42/C/Co, or Joe Sales/12AS/V/Co). The organization code for any one organization is consistent across ALL of our systems (Domino or otherwise)...and this is a very major key component of our deriving value from the Notes Name.
The OU2 values are managed via a single Notes database. We have around 15,000 different OU2 values (thus the need for a database to manage them.) Each value has a Notes document that has a bunch of organizational information (addresses, phonenumbers, etc.) and we have a common script library that is deployed to most of our Notes apps where we have built a custom class that instantiates with a parameter of that OU2 value and provides immediate access to that stored info.
The really cool thing about this whole setup is that the primary key into the OU2 database is ALWAYS available to us and there is no way it can be spoofed
Should we need to get an agency's commission plan, we can query our Oracle based policy administration system using the agent's OU2 value; should we need to get a list of all of a customer's (policyholder's) claims we can query our Progress based claim administration system using the customer's OU2 value; what about a vendor's open invoices? Query the MSSQL based accounting system with the vendorID from...you got it, the vendor's OU2 value. I think you get the idea.
All of our external data queries have parameters that 'validate' the requesting user's 'right' to query for the data and it comes from the built-in OU1 or OU2 values. There is no way for a user to get around this control...the query is built in Lotusscript or Java and the NotesSession/Session object 'knows' who the calling user is and it is a simple object assignment to get a NotesName object from the session.usernamelist property. Once you have the NotesName object, you have easy access to the individual components of the name.
One security benefit from this structure is that if you perform the same queries from a server id or administrator id, you will not get any data returned (because the scripts limit those at the OU1 level and we NEVER have to pass a 'primary' query parameter via a URL. Should an anonymous user somehow get access to one of our web apps and figure out how to 'run' one of our webqueryopen agents that queries an external system? Big deal...the anonymous account doesn't have the 'keys' built in and there is no way for the agents to have them 'injected' into the SQL query. This is especially beneficial for our webservices which are Domino agents or Domino pages...we don't have any parameters to pass...the webservice URL looks like https://www.myco.com/database.nsf/getpolicies?OpenAgent if you are an employee, you get the complete list of policies, if you are an agent, you get a subset of the policies that belong to your accounts, and if you are a customer, you get a list of your policies. All very elegant and very easy to maintain.
I find that one of the more powerful, yet often under utilized, features of Notes/Domino is the hierarchical name scheme. For a long time my only development exposure to the Notes Name was something like this: @Name([cn];@Username) and every time I wrote a statement like that I swore my vengeance on the developer who added hierarchical names to the product.
Today, much more experienced and hopefully wiser, I use Notes Names to the fullest and am extremely happy the hierarchical naming exists in the product.
In my current organization we use an O and two OUs in ALL of our usernames (both Notes created client users (user.id type users) as well as web browser based Domino users.) I don't know if other organizations create hierarchical names for their nonNotes client users, but they should, as you will soon see. Obviously, you can structure the hierarchy however you need to, below is how we use it.
O The Organization Level
We have a single O (organization) value. We are leaving it alone for now because of future business expansion planning.
OU1 The Relationship Level
We have 6 OU1s. E = employee, A=agent, C=customer, V=vendor, I=shareholder, and S=server. Most of our ACLs have at least an entry like */E/Co (Co represents our company initials.) Whatever access is granted to that single entry is granted to ALL of our employees...with no grouping required (we block terminated employees from ever reaching the server with a Server Access control.)
OU2 The Workgroup/External Organization Level
At OU2 we either identify the workgroup of our employees (Andy Broyles/IS/E/Co) or the organization code of our agents, customers, and vendors (John Smith/AB01/A/Co, Sally Brown/DW42/C/Co, or Joe Sales/12AS/V/Co). The organization code for any one organization is consistent across ALL of our systems (Domino or otherwise)...and this is a very major key component of our deriving value from the Notes Name.
The OU2 values are managed via a single Notes database. We have around 15,000 different OU2 values (thus the need for a database to manage them.) Each value has a Notes document that has a bunch of organizational information (addresses, phonenumbers, etc.) and we have a common script library that is deployed to most of our Notes apps where we have built a custom class that instantiates with a parameter of that OU2 value and provides immediate access to that stored info.
The really cool thing about this whole setup is that the primary key into the OU2 database is ALWAYS available to us and there is no way it can be spoofed
Should we need to get an agency's commission plan, we can query our Oracle based policy administration system using the agent's OU2 value; should we need to get a list of all of a customer's (policyholder's) claims we can query our Progress based claim administration system using the customer's OU2 value; what about a vendor's open invoices? Query the MSSQL based accounting system with the vendorID from...you got it, the vendor's OU2 value. I think you get the idea.
All of our external data queries have parameters that 'validate' the requesting user's 'right' to query for the data and it comes from the built-in OU1 or OU2 values. There is no way for a user to get around this control...the query is built in Lotusscript or Java and the NotesSession/Session object 'knows' who the calling user is and it is a simple object assignment to get a NotesName object from the session.usernamelist property. Once you have the NotesName object, you have easy access to the individual components of the name.
One security benefit from this structure is that if you perform the same queries from a server id or administrator id, you will not get any data returned (because the scripts limit those at the OU1 level and we NEVER have to pass a 'primary' query parameter via a URL. Should an anonymous user somehow get access to one of our web apps and figure out how to 'run' one of our webqueryopen agents that queries an external system? Big deal...the anonymous account doesn't have the 'keys' built in and there is no way for the agents to have them 'injected' into the SQL query. This is especially beneficial for our webservices which are Domino agents or Domino pages...we don't have any parameters to pass...the webservice URL looks like https://www.myco.com/database.nsf/getpolicies?OpenAgent if you are an employee, you get the complete list of policies, if you are an agent, you get a subset of the policies that belong to your accounts, and if you are a customer, you get a list of your policies. All very elegant and very easy to maintain.
|
Permalink
| Comments (3)
| TrackBacks (0)
Bookmark :
Comments
Posted by Nathan T. Freeman at 10:34:33 AM on 04/27/2007 | - Website - |
Posted by Jerry Glover at 05:33:28 PM on 04/27/2007 | - Website - |
Unfortunately I don't often get the chance to "do things right" because of the various toes that will get stepped on in the process. Kudos for pulling it off.
Posted by Kevin Pettitt at 02:54:14 PM on 04/30/2007 | - Website - |