Wednesday, February 25, 2009
The Amphibian of Identity Protocols
Anyone ever noticed how Mark Wilcox of Oracle, Pat Patterson of Sun and Kim Cameron of Microsoft all do a wonderful job of interacting with their customers in the blogosphere. Maybe someone could tell me why EMC is so horrific in this regard...
Anyway, back to something Mark said that I disagree with. His comment was:
Nowadays, business users understand UML notation as they may have been participants in RUP. Likewise, having a common notation in which to convey ideas is equally important in the new world where developers may be in India and need to communicate with the person who controls the schema who could be employed by another firm.
Indpendent of the tree structure which should be kept simple, one still should model objectClasses. In a large enterprise, you may desire to have different types of people that are extended from say Person or its derivatives. Independent of any inheritance construct, you may also want to indicate to developers via a model that say oraclePerson should be stored in ou=people where dfsPerson should be stored in ou=fugly. Anyway, I hope you will reach out to your customers and explore this thought deeper. Ludovic Poitou of Sun will hopefully share his thoughts in this regard as well.
As far as commentary regarding LDAP injection, I believe that it would be great if Mark and others from the LDAP crowd could spend more time understanding OWASP and not only at a personal level, but how their employer could benefit by becoming a member. In his example, he assumes that SQL injection type attacks require update capability where it may be sufficient to do things that are based on being read-only. So if I could read your credit card, SSN or whatever goodies you have in a directory then I don't think that write protection matters. Likewise, using OVD as a type of firewall is somewhat intriguing but also flawed. Maybe he could outline exactly what the constraint would look like since the odds are that the application would have valid rights to read the data just not in the exploited context.
In order to get to a higher-level of security, we would have to acknowledge that ACLs are suboptimal, that CARML-style declarations are nice but aren't industrial-strength enforcement mechanisms in an OWASP-style threat model...
| | View blog reactionsAnyway, back to something Mark said that I disagree with. His comment was:
- I don't think there is a need to model LDAP anymore - because applications basically dictate the organization and it's generally better to keep it simple. Have a root (e.g. dc=oracle,dc=com) and then have a couple of branches (e.g. ou=people, cn=users).
Nowadays, business users understand UML notation as they may have been participants in RUP. Likewise, having a common notation in which to convey ideas is equally important in the new world where developers may be in India and need to communicate with the person who controls the schema who could be employed by another firm.
Indpendent of the tree structure which should be kept simple, one still should model objectClasses. In a large enterprise, you may desire to have different types of people that are extended from say Person or its derivatives. Independent of any inheritance construct, you may also want to indicate to developers via a model that say oraclePerson should be stored in ou=people where dfsPerson should be stored in ou=fugly. Anyway, I hope you will reach out to your customers and explore this thought deeper. Ludovic Poitou of Sun will hopefully share his thoughts in this regard as well.
As far as commentary regarding LDAP injection, I believe that it would be great if Mark and others from the LDAP crowd could spend more time understanding OWASP and not only at a personal level, but how their employer could benefit by becoming a member. In his example, he assumes that SQL injection type attacks require update capability where it may be sufficient to do things that are based on being read-only. So if I could read your credit card, SSN or whatever goodies you have in a directory then I don't think that write protection matters. Likewise, using OVD as a type of firewall is somewhat intriguing but also flawed. Maybe he could outline exactly what the constraint would look like since the odds are that the application would have valid rights to read the data just not in the exploited context.
In order to get to a higher-level of security, we would have to acknowledge that ACLs are suboptimal, that CARML-style declarations are nice but aren't industrial-strength enforcement mechanisms in an OWASP-style threat model...
