Skip to main content

I'm working on a solution that would allow users to action work items from the email message via a blackberry.  I've seen the best practice document (http://www.k2underground.com/forums/thread/18017.aspx) and that's incredibly helpful, but one question I had was if the users are using devices that aren't on the domain, can it work with Forms or Basic Authentication?

I'm sure that I could use an account with elevated permissions, but that seems like a bad idea from an auditing perspective, it would also allow a user to action any item pretty easily if they could figure out the Serial number.  In the event that I have to store credentials used to connect to the server, what's the best "K2" way to store connection information?  (e.g. I know that I could use the registry or the DPAPI to store connection information, but I'm assuming that there's an accepted standard in K2)

 

For users who are not in a domain, you could authenticate against the K2 SQL database.  Look in your K2 database server at a database called K2SQLUM.  There are tables for users and groups.  You can use these users and groups as destinations just like AD users.  You will have to build your own form to collect the user and password, but then you can authenticate against K2 SQL using the SourceCode.Workflow.Client.Connection object.  There is good information on the connection string format on the Developer's guid and other threads on this site.

As far as I know, there isn't an approved "K2" way of doing this, but there are many ways it could be accomplished.


Because you are talking about creating a service that is going to "harvest" emails, parse them for actions, and execute actions against the K2 workflow server using the workflow.client, you have complete control over how you will authenticate with the K2 Server when opening the connection.  So getting access to the worklist item isn't the issue, the issue is confirming the identity of the email sender somehow and/or passing through their AD authentication information somehow to keep reporting clean. 


I would not suggest passing through any authentication information across email unencrypted.


Typically blackberries are generating email through a service running on your exchange server, so the trail of hidden smtp information in the email is consistent from mail to mail sent by any one individual.   What I would try first, is to use the from address to match up with the current destination for the worklist item you have open in your code, then do a background check on the email to ensure that it's delivery path is consistent with other trustable emails and the email is actually coming from the user you are expecting it to.  As this harvesting service will be developed outside of K2 workflow or smartobject VS projects/solutions, you will be able to easily update the formatting requirements and security logic over time.  This layer of security would function similarly to how your DMZ functions from a networking perspective.

The core security of such a solution would allow for the safe passing of AD credentials to aid in impersonation, you may want to consider using PGP or a similar solution to ensure that the email is coming from the expected source and to protect any credentials you include.

Sorry there isn't a standard answer for you, but I hope this helps,
Joseph


 


 

Reply


View our Community Site Map

Nintex Community Sitemap
Terms & ConditionsCookie settings