locked
HelloWorld Sample-CreateSession times out RRS feed

  • Question

  • hi,

    Can somebody tell, why should the CreateSession time-out .

    After clicking CreateSession button, the status continues to show "create session in progress", and after some time,  it times out.

    Links are all proper.

     thanks,.

    anita

    Monday, November 20, 2006 10:20 AM

Answers

  • Hi Anita,

    The exception you are getting occurs when the message is not satisfying the policy assertion. Please ensure that your message before it is sent to Session has Security header and under the Security Header it should have Usernametoken object. Apart from the above the username you are using to create the object should be a member of CSF_Requestors group.

    If all these are satisfied then i don't think there is any reason why you should get that exception.

    Thanks,

    Rishabh kapoor

     

    Thursday, November 23, 2006 1:12 AM

All replies

  • Hi,

    It might be happening that session got created but the CreateSessionResponse did not reach back the client application. You can have a look at Session input trace file to see if session received the CreateSession request and also check session output trace file to confirm that CreateSessionResponse was sent back.

    You can see the trace files under Connector\Session\Logs folder.

     

    Hope that helps.

    Thanks,

    Ashish Malhotra

     

     

    Monday, November 20, 2006 11:19 AM
  • hi,

    We had a look at the input trace at the location specified.

    We noticed that, there was an exeception getting thrown.

    <processingStep description="Entering SOAP filter Microsoft.Web.Services3.Design.RequireSoapHeaderAssertion+RequireSoapHeaderFilter" />


        <processingStep description="Exited SOAP filter Microsoft.Web.Services3.Design.RequireSoapHeaderAssertion+RequireSoapHeaderFilter" />


        <processingStep description="Entering SOAP filter Microsoft.ConnectedServices.Sdk.Security.DynamicAssertionServiceInputFilter" />


        <processingStep description="Exception thrown: Request message doesn't validate against any of the configured assertion.">   at Microsoft.ConnectedServices.Sdk.Security.DynamicAssertionServiceInputFilter.ValidateMessageSecurity(SoapEnvelope envelope, Security security)
       at Microsoft.Web.Services3.Security.ReceiveSecurityFilter.ProcessMessage(SoapEnvelope envelope)
       at Microsoft.Web.Services3.Pipeline.ProcessInputMessage(SoapEnvelope envelope)</processingStep>
      </inputMessage>
    </log>

     

    Any idea of why was this happening?

    Thanks,

    Anita.

     

    Monday, November 20, 2006 12:03 PM
  • Hi,

    What is happening here is that The Session Service has a Policy applied to it. Any other service which needs to communicate with this session service needs to fulfill the requiriments specified in Policy file for Session service and this is not happening in your case. Your client application is not fulfilling the policy requirements for Session Service.

    You can have a look at the policies that are specified by Session service when interacting with various other services in Configuration\SessionPolicyMapping.config file.

    According to this file any service (other than CSF Core services) which wants to communicate with Session service must fulfill the security assertion "SessionServerPolicy". security assertion "SessionServerPolicy" is defined in Configuration\SessionPolicy.config file.

    Now your participants must provide credentials as required by Session Service policy file. You can have a look at previous mails or documentation to understand how thiscan be done.

     

    Thanks,

    Ashish Malhotra

     

     

    Monday, November 20, 2006 1:08 PM
  • Hi,
    Thanks for all ur quick replies.
    In the last post, u mentioned to provide credentials required by Session Server Policy (in SessionPolicy.config).

    Policy is described as:

    <policy name="SessionServerPolicy">
      <authorization>
       <allow role="MyDomain\Requestors@CSF_Session"/>
          <deny user="*"/>
      </authorization>
      .
      .
      .
     </policy>


    so we gave following credentials for HelloWorld participant in the Manifest.xml,
    (credentials were windows credentials).

    <Participant timeout="30" role="Service" inChannelResponse="true" type="WebService">
            <ParticipantName>HelloWorldParticipant</ParticipantName>
            <ParticipantID>HelloWorldParticipant</ParticipantID>
            <ParticipantUrl>http://<machineName>/HelloWorldService/Service.asmx</ParticipantUrl>
          <SecurityToken>
            <UsernameToken>
              <Username>User@MyDomain</Username>
              <Password>password</Password>
            </UsernameToken>
          </SecurityToken>
          <PolicyDocument>
            <Reference>SecuritySessionPolicy</Reference>
          </PolicyDocument>

        </Participant>

    Still in input_trace we encountered exception,


      <processingStep description="Exception thrown: Request message doesn't validate against any of the configured assertion.">   at Microsoft.ConnectedServices.Sdk.Security.DynamicAssertionServiceInputFilter.ValidateMessageSecurity(SoapEnvelope envelope, Security security)
       at Microsoft.Web.Services3.Security.ReceiveSecurityFilter.ProcessMessage(SoapEnvelope envelope)
       at Microsoft.Web.Services3.Pipeline.ProcessInputMessage(SoapEnvelope envelope)</processingStep>

    Do we need to make changes in SessionPolicy.config also?

    Thanks,
    Anita.

    Monday, November 20, 2006 4:26 PM
  • Hi,

     

    I think you should roll back the changes. The problem here is not with Hello World service. The problem lies with the client application through which you are trying to send CreateSession request to Session. When sending CreateSession request you also need ensure that your request fulfills the policy requirements of Session service.

    The Session Service uses DynamicSecuriy assertion, which provides you a flexibility of either providing Kerberos tokens or UserNameTokes as credentials.

    So when ever a service/client application needs to communicate with seesion service, it must provide Kerberos tokens or UserNameTokes as credentials. 

    There are many ways to supply credentials - specifying credentials in code, applying policy to out going request, using Policy mapping etc. The easiest way for you right now would be to specify credentials in code as follows:

    message.Header.Security.Add(new UsernameToken("username", "password", PasswordOption.SendPlainText));

     

    The "Session Component" part of documentation clearly explains these.

     

    Thanks,

    Ashish Malhotra

     

     

     

     

      

    Tuesday, November 21, 2006 4:27 AM
  • Hi,

    thanks for ur reply.

    We specified the windows credentials in the code itself, while creating session as

    message.Header.Security.Add(new UsernameToken("username", "password", PasswordOption.SendPlainText));

    But still resulted in an exception (input trace)

    <processingStep description="Exception thrown: User 'username' is not authorized to access the service.">   at Microsoft.Web.Services3.Design.AuthorizationAssertion.AuthorizationFilter.ProcessMessage(SoapEnvelope envelope)
       at Microsoft.Web.Services3.Pipeline.ProcessInputMessage(SoapEnvelope envelope)</processingStep>

    So, how do we assign authorisation  to a user?

    Regards,

    Anita.

     

    Tuesday, November 21, 2006 6:11 AM
  • Hi,

    I dont think 'username' is a valid user account on your system. You need to specify a valid user account and password.

     

    Thanks,

    Ashish Malhotra

     

    Tuesday, November 21, 2006 6:55 AM
  • hi,

    thanks for ur responses.

    Windows credentials that we gave seem to be proper.

    We confirmed those using

    runas /user:MyDomain\Username calc.exe

    Thanks & regards,

    Anita.

    Tuesday, November 21, 2006 7:36 AM
  • Hi,

    Make sure you provide the credentials of an account that has permission to create new sessions to the Header.Security collection of the Message object. This account must be a member of the role that is specified by the <SessionManagerAdminRoleName> element in the Session.config file.

    Thanks,

    Ashish Malhotra

     

    Tuesday, November 21, 2006 8:26 AM
  • Hi,
    Thanks for all your previous replies.
    As mentioned in your earlier post,
    we added the following elements in Session.config.


     <SessionManagerAdminRoleName>MyDomain\Requestors@MyDomain_SessionManagerAdmin</SessionManagerAdminRoleName>
     <SessionAdminRoleName>MyDomain\Requesters@MyDomain_SessionAdmin</SessionAdminRoleName>
     <SessionUserRoleName>MyDomain\Requesters@MyDomain_Session</SessionUserRoleName>

     <TurnOffAuthorizationForAllRequests>false</TurnOffAuthorizationForAllRequests>

    After this also we still encountered the same exeception. Was it because we didnt specify the elements properly?


    Then, we later tried just disabling all security by making

    <TurnOffAuthorizationForAllRequests>true</TurnOffAuthorizationForAllRequests>

    still there was same exeception


    Any idea what went wrong?

    Thanks,
    Anita.

    Tuesday, November 21, 2006 11:27 AM
  • Hi Anita,

    The exception you are getting occurs when the message is not satisfying the policy assertion. Please ensure that your message before it is sent to Session has Security header and under the Security Header it should have Usernametoken object. Apart from the above the username you are using to create the object should be a member of CSF_Requestors group.

    If all these are satisfied then i don't think there is any reason why you should get that exception.

    Thanks,

    Rishabh kapoor

     

    Thursday, November 23, 2006 1:12 AM
  • Hi,

    Thanks for your reply.

    As stated, we have given the userNameToken in the header as:

    message.Header.Security.Add(new UsernameToken("username", "password", PasswordOption.SendPlainText));

    But any idea on how to make it a member of CSF_Requestors group?

    Thanks,

    Anita

    Thursday, November 23, 2006 5:54 AM
  • Hi Anita,

    Please note that CSF Installer creates a node named CSF Administrator OU on the domain controller.

    Please go to AD machine -> Look for Active Directory Users and Groups. Find CSF_Requestors group.

    There you will find three requestors group one for Session, second for SessionAdmin and third for SessionManagerAdmin.

    Add your user to SessionManagerAdmin to create the Session. On the Ad machine when you click the group you have the provision to add a user to the group. This is very similar to the way you add users to a group on your local machine.

    Hope this will help you.

    Thanks,

    Rishabh..

    Thursday, November 23, 2006 7:48 AM
  • Hi,

    Thanks to everyone for all quick and helpful replies.

    We are finally able to create session successfully.

    Thanks,

    Anita.

    Thursday, November 23, 2006 12:21 PM