locked
Problem trying to use authorization key IAG 2007 RRS feed

  • Question

  • I have a scenario I wish to configure in IAG 2007. When a user is presented with the portal view having successfully logged into the IAG, one of the applications available is a web site which expects the user id to be added in the querystring. so the application would be set as http://mywebsite?userid=fred

    I have gone through the manuals and decided that the solution would be to use the Authorization key in the application settings.

    So I added a line of code to the inc file mywebsite1postpostvalidate.inc similar to the following

    SetSessionResourceParam g_cookie, "4C66D0A2134344FFBC473997C849A123", "RWSAuthorization", Session("user_name1")


    and in the application setting in IAG configuration on the "web settings" tab, I select the Authorization Key and set this as a parameter with the name "userid" and set the url of the application to http://mywebsite   as an example.

    I haven't managed to get his to work and swithching the tracing on, the current failure point is at the setsessionresourceparam call in the inc file.

    The trace shows the following errors

    ** 19.02.10 17:13:52.852 SESSIONMGR_SERVICE:GENERAL T1844
    ERROR: Failed to SetSessionResourceParam [0x80140001]
    * at line 1442, file "src/SessionMgr.cpp".

    ** 19.02.10 17:13:52.852 INTERNALSITE:GENERAL T1844
    ERROR: Failed to SetSessionResourceParam []
    * at line 0, file "PostValidate.asp".


    So my question is, is this the best approach to pass the user name as a parameter to an application when using the querystring? if it is , can anyone explain how to get this solution to work?

    Many Thanks

    Monday, March 1, 2010 5:03 PM

Answers

  • Following further testing we have resolved this issue in the postpostvalidate.inc.

    We resequenced the order in which the actions take place and now have it working for both AD and authorisation type other.


    So it was not a bug as was suspected previously.


    • Marked as answer by ShaunMc Monday, March 8, 2010 4:19 PM
    Monday, March 8, 2010 4:18 PM

All replies

  • Authorization key feature is exactly the feature you want to use.

    I'm assuming you cut and pasted the ApplicationID from teh gui to the postpostvalidate.inc so that is right.  Assuming that, I suspect the problem is likely with session("user_name1").   I'd do two things.   Firstly run and internalsite trace and make sure this session variable actually contains the username.  if not, you found the problem and I suggest pulling teh username in from teh session using the getleaduser call.  If it does already contain the username, then try to first set a simple variable to the username and then use this variable in teh more complicaticed setsessionresourceparam call.  Something like:

    UserIDvariable = Session("user_name1")
    SetSessionResourceParam g_cookie, "4C66D0A2134344FFBC473997C849A123", "RWSAuthorization", UserIDvariable


    Hopefully one of these ideas works for you.

    Tuesday, March 2, 2010 11:17 PM
  • Hi Shaun,

    Just to throw out another idea.  This other idea would work if you want this particular application to be your initial application.

    Follow everything you've done so far in regards to URL sets for that application or just throw it into learn mode for testing/proof of concept sake.

    Create a postpostvalidate.inc file

    <%
    
    MyUser = Session("user_name1")
    
    if myuser = "dennis"
    then
    response.redirect http://mywebsite?userid=dennis
    'else if... etc... you can do Use case
    end if
    
    %>
    <%
    
    MyUser = Session("user_name1")
    
    response.redirect "http://mywebsite?userid=" & MyUser &
    
    %>


    Basically all I'm doing with this script is detecting who you are... then redirecting you once your authenticated.  The direct Mark and you were going toward would work if you dont want the application to be your initial application. 

    Keep in mind the application_ID changing can be a real problem.  Also if you use the copy and paste function, that ID is duplicated as well.  This wouldnt be an issue with what I propose...

    Thanks!
    Dennis



    Wednesday, March 3, 2010 8:43 AM
  • Mark,

    Yes I cut and pasted the Application ID from the configuration application.

    The username does contain the valid logged in user ID

    I have set a variable from the session username and passed the variable to the function, but get the same error.

    I have even converted the session variable to a string when setting my variable, just in case, to force a string as the parameter to the function, but still no joy.


    Thanks


    Shaun
    Wednesday, March 3, 2010 9:38 AM
  • Dennis,


    unfortunately it isn't used as an initial application, but to be used in a link on the portal homepage.

    However, I will remember your advice should I come across the need to set initial applications for certain users in the future.


    Thanks


    Shaun
    Wednesday, March 3, 2010 9:42 AM
  • I have just added some tracing and a call to the function IsSessionResourceExist(cookie,resource_id)

    The value returned was false. Should this be true, or would it be added once I have made a succesful call to SetSessionResourceParam (which is still failing)?


    if it should exist by the stage  postpostvalidate.inc has been executed, then I have checked that the app ID I use as resource_ID is identical to that on the "general tab" when editing the application on the trunk.


    Any thoughts on this? does this give any further clues?


    Thanks

    Shaun
    Wednesday, March 3, 2010 3:59 PM
  • ok,  further testing and debugging has led me to find that the resource id not existing is where the problem lies.

    I have now seen the RWSAuthorization key working when I set up a new dummy application and web site along with a test user in an AD group on it's own. I then used the AD group for authorising access to the application through the portal view links.

    When this was successful, the resource ID was seen to exist in the session.

    The user scenario that fails , is when the user is authenticated by a repository of type other. This user has no membership of any AD groups.


    Is this a bug? it sure looks like one to me.............
    Thursday, March 4, 2010 3:56 PM
  • Following further testing we have resolved this issue in the postpostvalidate.inc.

    We resequenced the order in which the actions take place and now have it working for both AD and authorisation type other.


    So it was not a bug as was suspected previously.


    • Marked as answer by ShaunMc Monday, March 8, 2010 4:19 PM
    Monday, March 8, 2010 4:18 PM