|
My understanding is the same as yours in that when you add HTTP
authentication directives to your HTTP configuration, then all requests for
protected resources are passed through the authentication module. That
module not only authenticates the user, but also checks the user's
authority. It may also change the job to adopt the user profile. I agree,
that's not very efficient.
It can also be more costly in that all users need a client license in
order to authenticate against IBM i. That may only be a problem if you want
to open your site to the public.
One alternative is to use an IBM i web portal, which enables you add user
profiles to the portal that are not associated with an IBM i authentication
resource (IBM i User Profile, LDAP entry, authorization list entry,
Kerberos entry). A web portal is an application that maintains user
profiles, user groups, menus and menu items, user and group authorities,
etc. Users are authenticated only once when accessing the application. User
authority is then checked when accessing menus. When a menu item is
selected, and its associated session is launched, there is no need to
authenticate while using the application.
On Wed, Jan 29, 2020 at 11:28 AM Justin Taylor <JUSTIN@xxxxxxxxxxxxx>
wrote:
It's my understanding that Apache offer Basic and Kerberos
authentication, and authentication is repeated for every subsequent
request. That seems inefficient to me. Are there more efficient methods
for authentication?
TIA
--
This is the Web Enabling the IBM i (AS/400 and iSeries) (WEB400) mailing
list
To post a message email: WEB400@xxxxxxxxxxxxxxxxxx
To subscribe, unsubscribe, or change list options,
visit: https://lists.midrange.com/mailman/listinfo/web400
or email: WEB400-request@xxxxxxxxxxxxxxxxxx
Before posting, please take a moment to review the archives
at https://archive.midrange.com/web400.
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.