How Do I Remotely Authenticate a User using ScreenSteps Live Remote Authentication?
Remote authentication is pretty simple to implement. Basically you authenticate a user on your server and then send a special string to ScreenSteps Live telling it that the user is valid. This lesson will explain how the string is generated.
Information Provided By ScreenSteps Live
When ScreenSteps Live redirects a user to your remote authentication url it sends along a couple of pieces of information in the query parameters:
• return_to_url: This is the url that the user requested on ScreenSteps Live. You will pass this back to ScreenSteps Live after the user authenticates so that ScreenSteps Live can display the requested resource to the user.
• timestamp: This is the time value that you can use when generating the MD5 hash.
The MD5 Hash
In order to information ScreenSteps Live that a user has permission to view content you must pass over an MD5 hash. The MD5 has is comprised of:
1) First name of the user
2) Last name of the user
3) Email of the user
4) External id (used to uniquely identify user, can be empty in which case email is used)
5) Organization (can be empty)
6) ScreenSteps Live remote authentication token (look in ScreenSteps Live Settings)
7) Time (unix time)
The URL
To notify ScreenSteps Live that a user has successfully logged in you redirect to a url and pass a number of parameters. The url you redirect is your ScreenSteps Live domain followed by /login/remote/. For example:
http://example.screenstepslive.com/login/remote
You can pass the rest of the information needed as GET parameters in the query string. You must pass all of the information used to make the MD5 hash EXCEPT for your ScreenSteps Live remote authentication token (this must remain secret). An example (broken up into multiple lines for readability):
http://example.screenstepslive.com/login/remote/?
first_name=FIRST_NAME&last_name=LAST_NAME&email=you%40domain.com&
external_id=EXTERNAL_ID&organization=ORGANIZATION×tamp=TIMESTAMP&
hash=MD5_HASH&return_to_url=RETURN_TO_URL
By passing over the information used to create the hash ScreenSteps Live can combine the secret remote authentication token with the information you passed over in order to confirm that the hash is valid. This keeps others from being able to log users in.

Is it possible to remote authenticate a user into protected content, but instead of giving that user the url to the space in "operation mode" (I don't know how to call it), give the user the public url? The content is not public, but the public url still works if the user is logged in. In sum, I'd like to remote authenticate the user that is given a public url of a protected space. Would this work?
Carlisia -
When you remotely authenticate a user we match the user up based on their email address. If you have given a user with that email address permission to view a protected space then they will be able to see the "public url".
If you a user logins using remote authentication and we don't find an email that matches for them at all in your ScreenSteps Live account then we create a new "reader" account for them. They have no access to your admin area and won't be assigned to any protected spaces. Essentially they have a reader account that only allows them to see public content.
I think the question you are asking is, can you create a new user and have them view a lesson in a protected space without first creating that user in ScreenSteps Live. Currently the answer is no. You need to create the user either via the User Provisioning API or the admin interface and assign them the appropriate space. Otherwise we have no idea what content you want them to see what content you want to hide from them.
We are looking at adding an option to pass back group information via remote authentication. That way you could just assign a group to your space on ScreenSteps Live. If the user was part of a corresponding group in your remote authentication, ScreenSteps Live would automatically log them into any protected information that group had permission to see. But that hasn't been implemented yet.
Does that all make sense?
Add your comment