Hi,
I'm looking to create an SaaS application that is cloud-based using AlphaAnywhere 2.0's current WebSecurity system.
The same application could be used by competitors in the same city servicing the same customers.
With an eye to keeping costs down because the data sets may not be all that large for any one customer, I'm looking to have a single data set used by all businesses using the application hosted in the cloud, where they and their customers would just be accessing it from their own individual web sites.
Let's say the application is a golf course management program that as one of its functions is to allow golfers to reserve tee times and post their scores and historically compare their scores for each course individually.
In addition, it allows the golf course themselves to collect greens fees over the web, look at the tee sheet for the whole day across all golfers, and other management tasks that are unique and confidential to the individual course.
So we have Tee It Up Golf Course, and Swing and a Miss Golf Course and Fore! Golf Course.
Ben Hogan lives near all of these courses and likes to play at each one because he enjoys variety, but Ben's a bit old and doesn't like multiple passwords and regardless of which web site for which golf course he wants to make a tee time, he wants to just use his email ([email protected]) and password (1234) to identify himself.
My current understanding of AA's web security is that each web user record is identified by a unique username/password pair, but those two items by themselves won't allow me to differentiate amongst the three courses (I don't think).
My thought was that if we could add a third component, ideally the domain of the web site that Ben was logging in from, that we could then have Ben in the user table multiple times as follows:
Now when Ben goes to log in, it's not just username/password, but domain/username/password that grabs the unique GUID that identifies which golf course he wishes to make a tee time for.
Similarly, the golf courses don't want to share their information with each other (which would be more than tee times and scores, but also greens fees, membership fees, etc.).
The golf courses want their own unique web sites with their own domains, which when the user enters in their credentials, the request is sent to the single hosted data set and filters out the data from the other two courses and only let's Ben see his activity for Tee It Up, as an example.
From the golf courses' perspective, their internal users would have a similar three-part credential paradigm, and when John Admin wants to see all of the activity for just his course, Fore! Golf Course, he would only see that courses' activity, even though Tee's and Swing's data is physically in that same dataset as well, albeit with different GUIDs.
In a nutshell, since Ben doesn't want multiple usernames/passwords just to set up a tee time and the golf courses don't want their data shared with anyone else, is there a way with the current AA web security system that this can be handled in a single application with a co-tenancy dataset?
Any thoughts on how to accomplish this would be appreciated. I'd like to stay as much as I can within the "canned" AA security framework as possible, although I realize it would be possible to completely roll my own,
Kevin
I'm looking to create an SaaS application that is cloud-based using AlphaAnywhere 2.0's current WebSecurity system.
The same application could be used by competitors in the same city servicing the same customers.
With an eye to keeping costs down because the data sets may not be all that large for any one customer, I'm looking to have a single data set used by all businesses using the application hosted in the cloud, where they and their customers would just be accessing it from their own individual web sites.
Let's say the application is a golf course management program that as one of its functions is to allow golfers to reserve tee times and post their scores and historically compare their scores for each course individually.
In addition, it allows the golf course themselves to collect greens fees over the web, look at the tee sheet for the whole day across all golfers, and other management tasks that are unique and confidential to the individual course.
So we have Tee It Up Golf Course, and Swing and a Miss Golf Course and Fore! Golf Course.
Ben Hogan lives near all of these courses and likes to play at each one because he enjoys variety, but Ben's a bit old and doesn't like multiple passwords and regardless of which web site for which golf course he wants to make a tee time, he wants to just use his email ([email protected]) and password (1234) to identify himself.
My current understanding of AA's web security is that each web user record is identified by a unique username/password pair, but those two items by themselves won't allow me to differentiate amongst the three courses (I don't think).
My thought was that if we could add a third component, ideally the domain of the web site that Ben was logging in from, that we could then have Ben in the user table multiple times as follows:
Golf Course | Domain | Username | Password |
Tee It Up | @TeeItUp.com | [email protected] | 1234 |
Swing and a Miss | @SwingMiss.com | [email protected] | 1234 |
Fore! Golf Course | @foregolf.com | [email protected] | 1234 |
Fore! Golf Course | @foregolf.com | [email protected] | 9999 |
Similarly, the golf courses don't want to share their information with each other (which would be more than tee times and scores, but also greens fees, membership fees, etc.).
The golf courses want their own unique web sites with their own domains, which when the user enters in their credentials, the request is sent to the single hosted data set and filters out the data from the other two courses and only let's Ben see his activity for Tee It Up, as an example.
From the golf courses' perspective, their internal users would have a similar three-part credential paradigm, and when John Admin wants to see all of the activity for just his course, Fore! Golf Course, he would only see that courses' activity, even though Tee's and Swing's data is physically in that same dataset as well, albeit with different GUIDs.
In a nutshell, since Ben doesn't want multiple usernames/passwords just to set up a tee time and the golf courses don't want their data shared with anyone else, is there a way with the current AA web security system that this can be handled in a single application with a co-tenancy dataset?
Any thoughts on how to accomplish this would be appreciated. I'd like to stay as much as I can within the "canned" AA security framework as possible, although I realize it would be possible to completely roll my own,
Kevin
Comment