Revision: 4437
Author: [email protected]
Date: Wed Oct 12 23:40:07 2011
Log: Edited wiki page DirectLoginSoapGeneralFlow through web user
interface.
http://code.google.com/p/openmeetings/source/detail?r=4437
Modified:
/wiki/DirectLoginSoapGeneralFlow.wiki
=======================================
--- /wiki/DirectLoginSoapGeneralFlow.wiki Fri Feb 19 07:41:44 2010
+++ /wiki/DirectLoginSoapGeneralFlow.wiki Wed Oct 12 23:40:07 2011
@@ -10,15 +10,22 @@
== Summary ==
-The trick about the !DirectLogin-Flow (SSO) is that you can go into a room
directly without having any !OpenMeetings account. You always use the same
(Admin!!) user to login via the Web-Service and then use
the !setUserObjectAndGenerateRoomHash method to set custom user-value to a
specific session. The Method !setUserObjectAndGenerateRoomHash returns a
HASH, you add this HASH as param in the URL and thats it.
+The trick about the !DirectLogin-Flow (SSO) is that you can go into a room
directly without having any !OpenMeetings account.
+The Single Sign On process is a token-based process where you first
request a API-HASH, then you validate the HASH, then you can access the
API-methods to create conference rooms or produce another HASH that can be
append to the URL to access a conference room directly.
+
+There is a special user-level in !OpenMeetings called "SOAP-Only" you
should use such an account if you plan to integrate !OpenMeetings in you
website and need to save the user/pass of the API user in your
PHP/Perl/Python website.
== Recommended Scenario ==
You would like that people can create a conference room via your
Application and return to that room several times. You only need to store
the room-Id in your application logic, and the authentication data if
the !OpenMeetings admin user to manage the SOAP connection.
-If a user wants to directly login into that room he does that in two basic
steps (Phase 2 and Phase 3 in the Graph):
- # Sets the User session (getSession, loginUser,
setUserObjectAndGenerateRoomHash)
- # Login into the Room, by adding the HASH from
setUserObjectAndGenerateRoomHash to the URL
+If a user wants to directly login into that room you should use this
sequence:
+ # Request a general API-token: SOAP/REST API Calls: getSession
+ # Validate the API-token: SOAP/REST API Calls: loginUser
+ # Generate a URL-token: SOAP/REST API Calls:
setUserObjectAndGenerateRoomHash
+ # Login into the Room, by adding the URL-token from
setUserObjectAndGenerateRoomHash to the URL
+
+The methods getSession/loginUser/setUserObjectAndGenerateRoomHash should
be invoked by a Server-Side Script! Calling them directly from the Client
is NOT recommended. Cause you don't want to share the USER/PASS for the
loginUser-API-Call with the client, the client only should get the
URL-token. This token is only one-time valid (or several times depending on
which API call is in use). And that way the client cannot abuse the API to
compromise your !OpenMeetings server.
The HASH of setUserObjectAndGenerateRoomHash is only one time valid! For
security reasons, otherwise people could take that link and send it by
email and so flood the system with not-authorized access.
--
You received this message because you are subscribed to the Google Groups
"OpenMeetings developers" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/openmeetings-dev?hl=en.
