AdobeHSAuthenticator best practices?

[mjt333]

Comments in LCSS sample apps typically say something like "You would likely use external authentication here for a deployed application; you would certainly not hard code Adobe IDs here."

Our app will be used by numerous (we hope) customers.  Each time a customer launches an app and connects to a room, the code is not going to authenticate using the customer username and password, it's going to authenticate using our developer username and password, right?  We will use AccountManager to dynamically create and delete rooms, but we're not going to dynamically create and delete customer accounts within LCCS, are we?

If our app is just going to authenticate using our developer account, why wouldn't we hardcode the account username and password in the app?  What alternative should we use?

Thanks!

[Raff_ · Accepted solution]

I am not sure I understand what you mean by "our app".

The way we envisioned a similar use case is that you have an "application service" that manages your customers (who they are, what their credentials are, how they pay you, etc.). This would be implemented in any of the supported languages (Java servlet, Ruby/Rails, C#/ASP, php, etc.)

In order to access an LCCS room your client application (Flex/AIR) will first authenticate into your service (so your customers will login using their credentials into your authentication system).

Then your applciation service will use the AccountManager API to create a room if required and to generate an authentication token for your user (you'll specify a userID, a user name, and possibly a role for that particular user).

Then your client application (Flex/AIR) will get back control and will receive the authentication token. At this point it will be able to connect to your room by passing that authentication token and it will "impersonate" the user that just logged in.

[mjt333]

Thank you, this answers my question.