vscheuber's blog

we got a lot of feedback after we announced the availability of Designer 1.2RC1 and RC2. most of the comments came from customers who were confused that we release a 1.2 version as an update to a 2.0M2 milestone. here comes the reasoning behind the version order and chaos:

Designer releases iteratively. this means at the beginning of each major release development cycle we define what the scope for this major release is. a major release is 1.0 or 2.0 etc. this initial scope is just a rough idea gathering and setting goals to say something like: in Designer 2.0 we want to see Version Control and Staging as the two major new feature areas and we want to improve our overall user experience etc.
then we break down this rough scope into milestones. this is where the iterations come in. so we broke Designer 2.0 into 7 milestones where M7 will be 2.0. we then get loaded at the beginning of each milestone and scope this milestone out in detail. usually beside our rough goals, we get A LOT of additional feedback from our customers which we try to absorb into one of the milestones. then we implement the milestone and get loaded for the next. we roughly fix about 500 bugs per milestone and get about 100 enhancements in.

now what happened with 2.0 M3 and 1.2:

at the time we scoped out Designer 2.0, there were no official plans for another official Designer release before 2.0. that's why we made the decision to start working on something called 2.0 at the beginning of this calendar year. but then, as things evolved, it turned out that we had to release another supported release of Designer together with IDM 3.0.1 (SP1). now since we develop iteratively, we don't branch our code base (at least we try notto branch if ever possible). so we basically had to put SP1 specific changes into our running 2.0 trunk. looking at what's new in SP1, it really would not make sense to release a Designer 2.0 just for Spitfire SP1 and we would not have any of our 2.0 main features in by then anyway. so we decided to do a marketing version 1.2 and release 2.0 M3 as 1.2 to the public so that it makes sense to the end customer who got 1.1 with IDM 3.0 and will now get 1.2 with IDM 3.0.1.

we are thinking of including a build number in the future so you could see what our "real" version is versus the marketing version. really, don't put too much weight into the marketing version. it's just a name.

in my last post i stated that we fixed over 900 bugs since designer 2.0m2. after posting i realized that i probably painted an inaccurate picture of what 2.0m2 was and what the overall product quality was. at least for people who are not familiar with the way we use bugs to manage the designer project it may be difficult to correctly interpret my statement. designer is high quality, extremely customer focused and constantly evolving.

most of novell engineering uses bugzilla as a development process, problem and enhancement tracking tool. bugzilla holds records - referred to as bugs - that are assigned to a responsible person and categorized into products and feature areas per product. each of these records (or bugs) has a severity and a priority assigned. the severity is set by the reporting party and is meant to indicate how important the record is where as the priority is assigned internally and determines the attention (importance) the record gets.

the severity field divides the records into two different groups: problems and enhancement requests. if a record's severity is set to "enhancement" it describes a non-existing but desired functionality. all other levels assume a problem and indicate the importance of the problem.

now what makes the difference between an enhancement request and a bug? at first this seams obvious but very often it is not: designer does not currently provide any team enablement features like version control. a record (bug?) which asks for team enablement and version control would thus be given a severity of "enhancement". if designer during a deploy was going to destroy data, a record (bug?) reporting this issue would probably be assigned a severity level of "major" or "critical". but there is a lot of space between these two examples. imagine designer behaves in a way that is unexpected (wrong?) for you. if you reported this and requested a change of behavior would that be an enhancement request or a problem report? difficult to say.

we in the designer team use bugs for release planning, too. whoever has an idea enters a bug. often the severity level doesn't even matters. then, when we get loaded to do our next milstone, we pull up all the open bugs and prioritize them. this way we make sure no idea is being forgotten. you as a customer can do the same. our bugzilla system is open for you. you have an idea or a problem? go to bugzilla.novell.com and tell us about it.

back to my original post: over 900 bug fixes does not mean we had 900 critical problems we fixed. it means that we worked down a queue of over 900 records in our bugzilla database who describe our current release. from the over 900 bugs approx. 110 were marked as enhancement requests right away. this leaves us with over 790 records. most of these are bugs reported by our internal test team. they try every day to break our code and report every success they have. this way we make sure what we ship is of shipping quality. so 2.0m2 was not a milestone that had over 900 problems, but 1.2 (2.0m3) is a release with loads of new features and many, many adoptions requested by you and many, many, many problems fixed before they even were able to hit you, the customer, because they were found by our internal test team.

the first release candidate for the new designer for identity manager 1.2 is available for you to download!

in my last post i drew the picture of a marble cake where role-based entitlements and workflow are the two differently colored doughs that make up the perfect cake when they come together. read on to get more details and even a piece of the cake to taste...

mixing the doughs
the example i gave in my last post was about handling exceptions in an automated provisioning solution where all resource provisioning activities are implemented through the role-based entitlement (rbe) framework. rbe allows exception management out-of-the-box through its static include and exclude lists on rbe policies. this way an administrator can do manual exception handling but what we are really looking for is taking the exception handling from the administrator to the end user. here is where the doughs start to merge. we will use workflows to manage the static include and exclude lists and have the person responsible for the resources approve the workflows. this way the user discovers the need for access to a certain system (which he has no access to because it has not been assigned to his role in the enterprise) and requests access through the web interface (user application). whoever is responsible for approving this rquest approves or denies and the exception is handled securely and policy compliant without administrator or help desk intervention.

baking the cake
now here come some more detailed baking instructions. technically there are two different approaches to make workflow manage the static include/exclude lists: one is creating a custom entitlement with values and the corresponding dirxml script policies to handle the static include/exclude lists and then have the workflow just grant or revoke this custom entitlement. the other way would be to have the workflow manage the lists directly through an entity activity (instead of an entitlement activity which is the default for identity manager 3.0). the second approach is much more straight forward but requires a little more knowhow about workflow, the first approach leaves the workflow part pretty much at the standard level of an out-of-the-box installation but requires some dirxml-script work. to save anyone who wants to try any of these approaches a headache, i have to mention here that Identity Manager 3 sp1 code is needed to make it all work. sp1 will be out this summer, so very soon.

tasting it
as i mentioned above, you need sp1 code to make the whole scenario work as discussed. since i want to give you something now that you can taste, i put together the custom entitlement and driver anyway and you can use it to manage static include/exclude lists but you will have to manually re-evaluate membership all your users to make the rbe service pick up the change until you run the driver that comes with sp1. an alternative approach which would work even without sp1 is to set a flag on the user object and include this flag in the dynamic member query but i prefer having the exception handled on the rbe policy rather than on all the user objects.

download this zip file containing a driver export with custom entitlements and dirxml script policies to manage the static include/exclude lists.

with identity manager 2 we introduced the role-based entitlements (rbe) framework. it allows you to grant or revoke resources through a common architecture based on role membership. with identity manager 3 we expanded the framework to also allow for approval-based resource provisioning. the documentation indicates that role-based and approval-based provisioning are mutually exclusive per resource. true?

roles let you specify static members (and non-members) and dynamic members. the dynamic member feature lets you specify a query that, on evaluation, returns the list of members. this way you can easily set up a policy called "managers" and have it gather its members by querying "class-name equals User AND isManager equals TRUE" instead of manually having to find and add all managers.

approval flows, on the other hand, usually don't include any dynamics other than finding the next approver. the approver approves or declines a resource request. the reasons an approver bases her/his decision on are beyond the reach of the software controlling the approval flow.

given the fundamental differences between the two, can we assume they are mutually exclusive for a single resource or even the whole provisioning system? e.g. does it make sense to allow access to an application be requested and at the same time grant that same access based on a role? absolutely! eventhough being black and white, role-based and approval-based make up a the perfect marble cake in a good architecture:

• identify resources which can be granted based on roles and which do not need approval in addition to the role membership (which can be seen as a passive approval). once this type of resources has been identified, rbe can be used to create a fully-automated role-based provisioning system.
• define whether exceptions can occur in the above architected system. what if a manager wants to delegate a performance management task to a senior employee with no manager grade but the role-based provisioning system only provisions managers to this application? this is definitely an exception that need to be taken care of. here comes the marble cake: approval-based provisioning can perfectly complement role-based provisioning to handle exceptions in a secure and policy compliant manner.
• identify resources which always need approval for compliance or other reasons. these resources should be excluded from role-based provisioning unless the roles are provisioned approval-based. so there are two approaches: either force approval for each single resource or force approval for role assignments and then have the roles grant access to all the resources necessary to execute that role.

in my next post i will give some technical insights on how to best make role-based and approval-based provisioning work together.

in my last post i asked you what console strategy you would prefer. i would now like to share some insights with you about what the designer for identity manager future holds. your posts have all been received and in my hallway where my office is i was called "trouble maker" for 2 weeks after my post.

see how designer for identity manager is going to address the issues that were brought up.

for the public, designer for identity manager started off as an offline only tool and we got overwhelmingly positive feedback to this new approach. now that designer for idm is in the maturing phase, we get a lot of requests for "live" features. you and others told us that it is awkward to alt+tab over to imanager, do an object modification, watch the trace to see the result and then alt+tab back to designer to make changes to the driver configuration, run the changes through the simulator, deploy them and again alt+tab back over to imanager.

we cannot comlete the whole visionary picture in a single milestone but we work one stroke of a brush after the other. some strokes have been painted long ago like the ability to start/stop/status drivers from designer and some are being painted at this very moment. in our next milestone release you will get access to another experimental live feature: an identity vault browser with object access.

the identity vault browser lets you browse every idv in your current project and allows to login to any other tree as well. the feature currently allows you also to edit any object with a generic object/attribute editor and you will be able to define customized ui for your schema on a per object class basis. in one of the future milestones we will add object creation, rename, move and delete.
imanager remains the primary edirectory administration tool for anything that goes beyond the above mentioned capabilties. designer and imanager are the yin and yang of idm management.