Understanding the documentation for Single Sign-On (SSO)

(4 posts) (2 voices)

Tags:

  1. shem, Member

    I am trying to understand the instructions at
    https://mydbr.com/doc/?prefs.sso.html

    I understand most of the instructions, but I don't understand the very first one.

    1. A user visits the myDBR site for the first time[i]

    My application does many things and sometimes a user clicks a button to make a call to myDBR (i.e. Renders a Report URL) to generate and display a report, which is embedded in the application page.

    So when you say user visits the myDBR site for the first time, do you mean the first time the user chooses to generate a report, or do you mean that every user who logs in to my application, should first thing make a call to myDBR.
    For the purposes of this post, so that we understand each other, I will assume the latter.

    If so, then I assume my application server simply references the general URL of
    myserver/mydbr/index.php
    How does myDBR know that the user is visiting the myDBR site for the first time?
    What distinguishes between two different users who would be causing the application to go to
    myserver/mydbr/index.php

    The following is my understanding of the rest of the steps - in very shorthand. Please tell me if I am correct:
    2. myDBR sends an API request i.e. a URL (which I define in myDBR environment settings) to my server, which verifies that the API call came from myDBR, and then displays my servers usual login screen.

    3. My Server performs its usual login of the user

    4. When the login succeeds, I redirect the user back to myDBR to the URL provided by myDBR in Step 2 (adding parameters to the URL as described in the documentation)

    5. "myDBR verifies the hash received from the SSO server and creates or updates the user information for the specified users"
    Can I assume that myDBR will return a success/fail code to my server which made the call to redirect the user?

    6.

  2. myDBR Team, Key Master

    So when you say user visits the myDBR site for the first time, do you mean the first time the user chooses to generate a report, or do you mean that every user who logs in to my application, should first thing make a call to myDBR.

    Calling myDBR first is not needed. You can let the SSO work in the background when the first call to myDBR URL is made.

    How does myDBR know that the user is visiting the myDBR site for the first time?

    When myDBR does the SSO login, the user gets session in myDBR. When there is no session, myDBR knows this is the user's first call and the login needs to be done.

    What distinguishes between two different users who would be causing the application to go to myserver/mydbr/index.php

    Each user has unique session in myDBR.

    5. "myDBR verifies the hash received from the SSO server and creates or updates the user information for the specified users"
    Can I assume that myDBR will return a success/fail code to my server which made the call to redirect the user?

    At this point there should be no errors as your SSO implementation eiter works or not.

    When you are implementing the SSO protocol, you can set the debug flag on in user/defaults.php:

    $mydbr_defaults['single_sign_on']['debug_failed_login'] = true;

    This will give you all the details for the failed login. Do not keep the setting on in the production server.

    --
    myDBR Team

  3. shem, Member

    I apologize for my lack of understanding, but this is hard for me to understand.
    In the meanwhile I will drill down further into my questions:

    Question #1
    I asked above
    What distinguishes between two different users who would be causing the application to go to myserver/mydbr/index.php?
    You replied
    Each user has unique session in myDBR.
    But if my direct url to mydbr is assembled as follows:
    $direct_url = $requestType . $hostname . '/mydbr/report.php?r=' . $reportId . '&m=1&h=' . $reportHash . "&u1=" . $some_param;
    Then my application is not sending any user information to mydbr to identify himself.
    So when myDBR receives the HTTP request, how does it know to create a session from one HTTP request of the above URL to be distinguished from a second call to the identical HTTP request?

    Question #2
    you wrote above
    Calling myDBR first is not needed. You can let the SSO work in the background when the first call to myDBR URL is made.
    I might be able to understand how my PHP Login code would make an HTTP request to myDBR and then do nothing until myDBR sends an API call to my application to handle the SSO, and only then bring the user to our main page.
    But if my initial HTTP request to myDBR is just a direct url for some report, which is in some object tag in some html code, then I have no understanding of how that can be synchronized with waiting on the myDBR API call to my application !

    Question #3
    Regarding steps 4 and 5 above
    Are you saying that at the same time I "redirect the user back to myDBR to the URL provided by myDBR in Step 2 (adding parameters to the URL as described in the documentation)", that I can assume the myDBR hash verification will succeed and the user will get logged in?

    Question #4
    Looking at the sso code samples you provide in mydbr/user/sso
    I see two files
    The file sso_example.php seems to be the API that I must set up within my application.
    So do I make a POST request to http://localhost/mydbr/user/sso/sso_example.php with all the parameters as json body parameters?
    Can you give me an example of how I would make this request?

    Question #5
    What is the file mydbr/user/sso/php_BB_sso.php?

    Question #6
    Is there a simpler alternative to SSO
    For example, is there such a thing as a myDBR API where I would pass a username and password and myDBR would return to me a token which I could store in the user session of my application, and then pass this token to every report request for a myDBR report?

  4. myDBR Team, Key Master

    Question #1
    So when myDBR receives the HTTP request, how does it know to create a session from one HTTP request of the above URL to be distinguished from a second call to the identical HTTP request?

    myDBR keeps session for users that have been authenticated via SSO. When an URL is called without myDBR identifying the user, the SSO login is performed. Any subsequent URL calls from that user are done under that user in myDBR.

    Question #2
    But if my initial HTTP request to myDBR is just a direct url for some report, which is in some object tag in some html code, then I have no understanding of how that can be synchronized with waiting on the myDBR API call to my application !

    If you have an object tag that you want to populate with myDBR report and the user invokes the call (via button or otherwise), you will place the myDBR report URLL to object tag's data attribute. The user's browser starts fetching the content from myDBR. When the call comes to myDBR, myDBR checks if the user is known to myDBR (does user have a session in myDBR), if not, myDBR calls your SSO endpoint which will give back the user data (username, name, email etc.). myDBR when will create the session for the user and run the report and returns the content to your object tag. All invisible to user in the background.

    Question #3
    Regarding steps 4 and 5 above
    Are you saying that at the same time I "redirect the user back to myDBR to the URL provided by myDBR in Step 2 (adding parameters to the URL as described in the documentation)", that I can assume the myDBR hash verification will succeed and the user will get logged in?

    If you have implemented the SSO protocol correctly, then yes.

    Question #4
    Looking at the sso code samples you provide in mydbr/user/sso
    I see two files
    The file sso_example.php seems to be the API that I must set up within my application.
    So do I make a POST request to http://localhost/mydbr/user/sso/sso_example.php with all the parameters as json body parameters?
    Can you give me an example of how I would make this request?

    The sso_example.php is just an example, do not use that in production. Create an entry point yourself. We will send you sample code.

    Question #5
    What is the file mydbr/user/sso/php_BB_sso.php?

    It is another sample code for SSO implementation. This time for phpBB software.

    Question #6
    Is there a simpler alternative to SSO
    For example, is there such a thing as a myDBR API where I would pass a username and password and myDBR would return to me a token which I could store in the user session of my application, and then pass this token to every report request for a myDBR report?

    We'll send you sample code. The SSO implementation is simple once you get the grasp of it.

    --
    myDBR Team


Reply

You must log in to post.