We need to modernize our way of authenticating our clients. Our current solution is +10 years old and doesn't cut it anymore. Clients need to authenticate against our system when for instance logging in and making a payment or changing their products.
Can I get some help from the more modern approaches that's now supported by OE?
Caveats:
We have our clients in a custom table in the database, not any built in table like _users etc. This will not change. It's not about database access, it's about application access. I can basically make any changes whatsoever to this table so if new datatypes are needed - no problem.
We run Classic Webspeed. Stateless. This is not likely to change very soon.
Apart from that we are very good with general web development (as well as webspeed) so we could roll it ourselves if needed - but we rather not invent another wheel if we don't really need to.
OE11.6, 11.7 coming soon, Linux.
Authentication with database in OE for Webspeed is possible with PAS for OE. It gives you the ability to validate your credentials with your database records and creates a Client-Principal. This Client-Principal will act as a token for your user and can be used for the life of that HTTP session. In Classic Webspeed, we do not support Client-Principal but in PAS for OE we can do various kinds of authentications(LDAP/AD/database(OERealm)/OAuth2) and URL Authorization.
For more details, please take a look at this whitepaper. I can provide more details if you are interested.
Thanks but PAS is currently not an option. So far this is the only really good use case we've seen and I don't see this perticular thing being worth the extra cost of PAS.
Migrating to PAS would also require a quite significant work in changing our routing. We have a some 7000 URL's based on rewriting "fancy urls" to match the cgi-wrapper.
If there are any ways to utilize some parts of the client-principal at all in classic webspeed I am all ears.
Jens,
In 11.1 and later, there is a feature known as 4GL authentication callbacks. These are procedures you write that will be called automatically to authenticate user connections. I don’t know if they will suit your needs, but you should have a look.
Sorry but I don’t recall in which manual these are described.
Thanks, I'll search the documentation for it!
Maybe I should have said that I would prefer this not interfering with the overall authentication against the database, tables and such.
We use a separate "client" role for connections against the DB via webspeed etc. Inhouse users have individual records for connecting to the DB.
I would reiterate Irfan's point that you should be using a CLIENT-PRINCIPAL in your code, and using that as the source of identity. This will allow you to move the verification of the user's credentials out of the business code into a separate service (even if you are starting with a logical service, as opposed to a separate AppServer).
Using the 4GL callback requires use of a client-principal object.