CardSpace & Workflow Foundation: creating managed cards as a workflow activity
Recently I posted mainly about CardSpace, but my mission is actually about all our application server technologies! Workflow Foundation is the perfect tool for describing & driving processes: and what is the generation of a managed card, if not a step in account provisioning? So I wrote a barebone sample activity, which wraps Garrett’s Card Writer sample .exe and allow you to implement the card generation task as a first class citizen of a workflow. The example can be found here: below there’s an except of the accompanying document.
The creation of a managed card will often be part of a more complex process, such as an account provisioning workflow.
Prior to the creation of a card there will be steps in which information is gathered, such as which smartcard should be used for backing the managed card. After the card has been generated there will be the need to make it available to its intended user, hence the newly created card will have to be processed by delivery logic. Those are just two examples of activities that may be performed in the context of the emission of a managed card: wrapping the card issuing task in an activity has clear advantages, as it allows streamlining of the process and all the usual advantages of representing business logic in form of workflow.
The current proof of concept demonstrates how you can use a workflow activity for 1) gathering the card generation parameters and 2) issue a managed card, whose bits will be available for further processing to the subsequent stages of a workflow.
The Managed Card Creation Activity does not contain any card generation code: it takes advantage of the excellent CardWriter tool sample, available at http://cardspace.netfx3.com/files/folders/samples-july-ctp/entry4926.aspx. This arrangement avoids branching the card generation sample code, that is free to evolve independently from the current sample (provided that the INI format for card description won’t change).
Please refer to the same CardWriter sample for understanding the meaning of the parameters that define a managed card.
The current implementation is a bare bone example, but it’s naturally possible to push the level of sophistication as desired.
The Managed Card Creation Activity
A screenshot of the ManagedCardCreationActivity properties is shown below:
Figure 1: UI Screenshot
The ManagedCardCreationActivity finds the card writer .exe by examining the path specified in the AppSettings key CardGenPath, which MUST be present in the hosting workflow’s config file.
Please refer to the documents in http://cardspace.netfx3.com/files/folders/samples-july-ctp/entry4926.aspx for the meaning of the card-specific parameters.
Using the ManagedCardCreationActivity implies filling with the correct values all the fields (unless already covered by a template). There are no validation steps in the current implementations. Furthermore, errors in the card generation code will be hard to spot as the operation is performed by an external exe. Simply get the temp INI file and explicitly launch the card writer .exe file against it in a console window for detailed error output.
Notes on CardData: After the Activity execution this property will contain the CRD file in form of string. You can move those data around, but if you modify it you will invalidate the card signature.
Notes on CardPath: After the Activity execution this property will contain the path in which the CRD file has been saved
Notes on TemplatePath: The TemplatePath property can be assigned via config file, in the AppSettings key TemplatePath. When assigned via config settings, TemplatePath points to a INI file that will be used at construction time for prepopulating the card parameters. This is especially useful for values that will seldom change, such as the issuer details. Since the initialization happens at construction time, you have to make sure that the InitializeComponent autogenerated method of the hosting workflow will not clean the activity properties.
3 Comments