• Replies 14 replies
  • Subscribers 0 subscribers
  • Views 119 views
  • Users 0 members are here
Options
3sides - Social sharing widget
Related

Securely load custom content in web page

Laura Jacobsen
27394

I have a requirement to load a custom developed web page in an iframe in a page on a Collaborate site. The custom web page is hosted in Azure and contains confidential information. Normally I would implement authentication on the custom web page to prevent unauthorized access. However, our business is requesting that users not be required to enter a separate set of credentials because they have already logged into HighQ.

It is a hard requirement that access to the custom page should be locked down to authorized users, but paradoxically, the users must not be required to log in. I need to find a way to make it so that my custom page can only be accessed via this particular iframe on the HighQ page. How might I go about this?

One thought I had was to implement some kind of token system and append a token to the iframe src URL. Does HighQ have a way to securely store such values so that it wouldn't have to be hard coded into the page source?

Parents

  • I know I'm coming to this thread very late. Some very cool ideas here. Ryan D'Souza and Andrew Quinn I will likely follow up on your interesting posts above. Here is an idea. Let me know what you think.

    • Create an iSheet in the site with a single custom column: Token.
    • Set the iSheet to not appear in lists.
    • Set permissions on the iSheet to View-Own.
    • Set a view (or the default view) to show just Created by (email address) and token.
    • When there is a site user who will need access to the external application, have a System Admin first change the permissions to add Edit-Own, then proxy login as that user, go to the iSheet page (you will need to have copied the URL down from when logged in as the admin) and create a new record with a randomly generated token value.  Then log back in as the Sys Ad, remove Edit-Own rights, so that users cannot edit or delete their own records.
    • When a user accesses the page where the integrated application is shown, retrieve the data from that view using the XML link.  That will return ONLY the row that the user "created" (although this was done via proxy login).  Pass the user's email address (better to pass the UserID or obfuscated UserID instead) and token to the external application.
    • The external application will then make a REST call back to Collaborate as a System Admin and retrieve all of the records in that iSheet and will filter out to get just the row where Created By = the email address that was passed to it.  If there is such a record, check to see if the token passed in is the same as the token in the iSheet. If so, the user is authenticated.

    I don't like that the token is static. (It would be great if the permissions were more granular, allowing the user to create a record and view it, but not edit or delete it later, to avoid some of the extra steps above.) Conceivably you could set up an sys admin cronjob that runs daily and updates the token value for every row in that iSheet to mitigate the concern that the token is static. At the end of the day, a user could share their login credentials with someone else, so if they can share their token with someone else that raises the same concerns.

    Will that work?

Reply

  • I know I'm coming to this thread very late. Some very cool ideas here. Ryan D'Souza and Andrew Quinn I will likely follow up on your interesting posts above. Here is an idea. Let me know what you think.

    • Create an iSheet in the site with a single custom column: Token.
    • Set the iSheet to not appear in lists.
    • Set permissions on the iSheet to View-Own.
    • Set a view (or the default view) to show just Created by (email address) and token.
    • When there is a site user who will need access to the external application, have a System Admin first change the permissions to add Edit-Own, then proxy login as that user, go to the iSheet page (you will need to have copied the URL down from when logged in as the admin) and create a new record with a randomly generated token value.  Then log back in as the Sys Ad, remove Edit-Own rights, so that users cannot edit or delete their own records.
    • When a user accesses the page where the integrated application is shown, retrieve the data from that view using the XML link.  That will return ONLY the row that the user "created" (although this was done via proxy login).  Pass the user's email address (better to pass the UserID or obfuscated UserID instead) and token to the external application.
    • The external application will then make a REST call back to Collaborate as a System Admin and retrieve all of the records in that iSheet and will filter out to get just the row where Created By = the email address that was passed to it.  If there is such a record, check to see if the token passed in is the same as the token in the iSheet. If so, the user is authenticated.

    I don't like that the token is static. (It would be great if the permissions were more granular, allowing the user to create a record and view it, but not edit or delete it later, to avoid some of the extra steps above.) Conceivably you could set up an sys admin cronjob that runs daily and updates the token value for every row in that iSheet to mitigate the concern that the token is static. At the end of the day, a user could share their login credentials with someone else, so if they can share their token with someone else that raises the same concerns.

    Will that work?

Children
No Data