Posts tagged password reset

I published all the source code for the OTP Demo I did over at TEC at https://github.com/ikrima/Public-Development

The source code contains a sample password reset activity using the interactive activity, the SMS One Time Password Authentication activity, an aspx web app that allows you to perform web based password reset, and the necessary public client extensions that allow you to talk to interactive activities (it would be easy to extend it to communicate to the OOB Password Reset Activity)

So I’m speaking at The Experts Conference (TEC) this year in vegas.  I have two presentations and as I’m wrapping up writing them, I realized that there’s just way too much content for two one hour presentations.  So I carved out the important bits but I figured I’d ask the interweb about the rest: what would you like an emphasis on?

Presentation 1: How to write custom authentication activities in FIM (e.g. OTP)

- Writing GINA Win32 UI (so your activity shows up in GINA)

-Extending the public client to talk to authentication activities for password reset

-Writing interactive activities (e.g. a non-password reset activity)

Presentation 2: Delegation model in FIM

- Which example should we work through: Approve on Behalf of vs. Password Reset on behalf of (It admin resets the password of another user)

-Go into detail about extending the public client to talk to interactive activities

-How to write activities invoke authorization workflows on the user’s behalf (impersonation)

To do this bulk load, you have to understand how the FIM engine stores authentication information. To make this simple, let’s use the User Ikrima as our user, the default QA Activity as the authentication activity, and the default authentication workflow as our example (but you can generalize to everything else)

• Ikrima has a multi-valued attribute (AuthNWFRegistered ) that lists all the workflows that he has registered for.  This attribute normally gets populated by FIM when Ikrima finishes registration.

So, to programmatically register Ikrima, you would need to insert the GUID of the default AuthN Workflow (9c3aca59-a85c-437f-bb67-9ce5a70521d7) into Ikrima.AuthNWFRegistered

• Now each activity in your AuthN workflow stores its registration data in GateRegistration Objects (the workflow engine creates these objects, the activity is only responsible for providing the data it needs to store).  So, you’ll need to use the FIM Public client to create those objects.  Some activities (such as the PasswordCheckGate & LockoutGate) do not need to create registration data.  The QA Activity does.

So what goes inside a GateRegistration Object? Well, here are the attributes you need to fill

1. GateID - This identifies which instance of the QA Activity in that workflow this registration data is tied to.  For example, if we had two different QA Activities inside one workflow, which one does this Gate Registration Object belong to?  That’s what GateID is for.  What is the format of GateID?  Well, it’s the QualifiedName of the activity (in the workflow context, you can retrieve it from Activity.QualifiedName).  But where else can you retrieve this?  Look at the XOML of the workflow definition.

<ns0:AuthenticationGateActivity ValidationError="{x:Null}" x:Name="authenticationGateActivity3" RegistrationData="{x:Null}" ChallengeResponse="{x:Null}">
    <ns0:AuthenticationGateActivity.AuthenticationGate>
      <ns0:QAAuthenticationGate ResponseTimeout="00:05:00" NumQsReqCorrectAns="3" NumQsReqRegistration="3" NumQsRandomPresented="3" NumQsDisplayedForReg="3" ValidationError="{x:Null}">
        <ns0:QAAuthenticationGate.Questions>
          <x:Array Type="{x:Type p9:String}" xmlns:p9="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">
            <ns1:String xmlns:ns1="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Customized Question 1</ns1:String>
            <ns1:String xmlns:ns1="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">Question Custom 2</ns1:String>
            <ns1:String xmlns:ns1="clr-namespace:System;Assembly=mscorlib, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b77a5c561934e089">The 3rd question</ns1:String>
          </x:Array>
        </ns0:QAAuthenticationGate.Questions>
      </ns0:QAAuthenticationGate>
    </ns0:AuthenticationGateActivity.AuthenticationGate>
  </ns0:AuthenticationGateActivity>

You can see, the Activity name is “authenticationGateActivity3”.  

1. GateType - This used to specify the type of activity tied to this GateRegistration object.  For example, it would distinguish between LockOut Activity vs. QA Activity.  To my recollection, this isn’t used anymore.  But, the QA GateType ID is 45C4D8BB-D34C-453d-8346-C9061A2A1E4C
2. UserID - This is the GUID of the Ikrima user object
3. WorkflowDefinition - This is the GUID of the Password Reset AuthN Workflow: 9c3aca59-a85c-437f-bb67-9ce5a70521d7
4. GateData - Now this is the custom data that the QA Gate activity stores.  If you look at the public client solution, you can see that other people have reverse engineered this data format.