AdobeHSAuthenticator best practices?

Comments in sample LCSS apps usually say something like "you should probably use external authentication here for an application deployed; you would certainly not difficult code Adobe ID here. »

Our application will be used by many (we hope) customers. Whenever a client launches an app and connects to a room, the code does not have to authenticate by using the client user name and password, it will authenticate using our developer username and password, right? We will use an interlocutor dynamically create and delete rooms, but we aren't going to dynamically create and delete accounts of clients within companies low-cost, are we?

If our application is just going to authenticate by using our developer account, why don't hardcode us the username of the account and password in the application? Should what alternative we use?

Thank you!

I'm not sure that understand what you mean by "our application."

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

In order to access a room LCCS your client application (Flex/AIR) will authenticate it first in your service (so that your customers will be connect by using their credentials in your authentication system).

Then your applciation service uses the caller to create a room if needed and to generate an authentication for username token (you will specify a user name, a user name and possibly a role for this particular user).

Then, your client application (Flex/AIR) control can answer and will receive the authentication token. At this point, it will be able to connect to your room by the way this authentication token and it will "borrow" the user who just logged in.

Tags: Adobe LiveCycle

AdobeHSAuthenticator best practices?

Similar Questions

Maybe you are looking for