Last week at my day job we concluded that the model has progressed far enough that we'd like to refocus our efforts from developing the model to actually using it to solve some problems. This week we met twice and began tackling the tricky issue of testing IDs.
What's so tricky about testing IDs? Maybe it's not so difficult to test a little application that has it's own list of users and associated permissions. But think about a large enterprise with infrastructure services for identity and security. Developers (and potential vendors) are encouraged to externalize security from their applications by leveraging the infrastructure services. For example, don't build a user store into your application; don't even prompt the user for ID and password that then gets verified against the enterprise directory. Instead, rely on the enterprise authentication services to authenticate a user and to assert the user's identity into the application; rely on enterprise authorization services to make consistent policy-based access decisions that can be leveraged by the application. In an enterprise environment like that, how do you create a testing ID that can be used to exercise the functionality of one application without enabling the testing ID to inappropriately access any other applications or data beyond the application being tested? For example, if a testing ID for one application needs to appear as a manager and a US citizen, how can we ensure the testing ID cannot be used to inappropriately access other applications or data that is intended only for managers and/or US citizens? It's tricky.
Anyway, we found the model in its current state to be very useful. It was a big help to have everybody looking at the same picture and definitions, so we could effectively communicate our various ideas to each other. After we finalize our approach for testing IDs, we hope to use the model to help us figure out our desired approach to privileged accounts, Subjects with multiple Personas, what identifier to use where (e.g., persona identifier vs. account identifier), shadow accounts for users at federated partners, reorganize some of our LDAP Directory Information Tree, etc.
What's next for the model outside my day job? I hears some murmurings of people interested in developing an identity model at some forum better suited to collaboration. We'd love to participate in an effort like that, and we'd be happy to share the contents of this blog in the hopes that it would be helpful.
Subscribe to:
Post Comments (Atom)
No comments:
Post a Comment