Discussion:
Remote authentication
(too old to reply)
Clark Smith
2019-05-23 14:55:49 UTC
Permalink
The way to delegate authentication chores when logging in under
Linux implies the use of PAM - which is not officially supported under
Slackware.

I am guessing that one can shoehorn PAM into Slackware, but I was
wondering if there is another mechanism to accomplish the same thing
under Slackware?
K Venken
2019-05-23 15:01:58 UTC
Permalink
Post by Clark Smith
The way to delegate authentication chores when logging in under
Linux implies the use of PAM - which is not officially supported under
Slackware.
I am guessing that one can shoehorn PAM into Slackware, but I was
wondering if there is another mechanism to accomplish the same thing
under Slackware?
Would nss_ldap be a solution? Otherwise, NIS is still available.
Clark Smith
2019-05-23 16:08:30 UTC
Permalink
Post by K Venken
Post by Clark Smith
The way to delegate authentication chores when logging in under
Linux implies the use of PAM - which is not officially supported under
Slackware.
I am guessing that one can shoehorn PAM into Slackware, but I was
wondering if there is another mechanism to accomplish the same thing
under Slackware?
Would nss_ldap be a solution? Otherwise, NIS is still available.
Isn't that for authorization, rather than authentication? I was
under the impression that the NSS stuff (NIS being one of the backends
that NSS can use) kicks in after a given user has been successfully
authenticated.
Henrik Carlqvist
2019-05-23 21:03:15 UTC
Permalink
Post by Clark Smith
Post by K Venken
Would nss_ldap be a solution? Otherwise, NIS is still available.
Isn't that for authorization, rather than authentication? I was
under the impression that the NSS stuff (NIS being one of the backends
that NSS can use) kicks in after a given user has been successfully
authenticated.
NIS is able to serve a passwd map to NIS clients which will use that map
to authenticate users at login. Once logged in NIS is also able to serve
a group map to authorize the users to different unix groups.

I haven't used LDAP myself for these purposes but think that you can do
the same with LDAP.

regards Henrik
Clark Smith
2019-05-23 21:40:48 UTC
Permalink
Post by Henrik Carlqvist
Post by Clark Smith
Post by K Venken
Would nss_ldap be a solution? Otherwise, NIS is still available.
Isn't that for authorization, rather than authentication? I was
under the impression that the NSS stuff (NIS being one of the backends
that NSS can use) kicks in after a given user has been successfully
authenticated.
NIS is able to serve a passwd map to NIS clients which will use that map
to authenticate users at login. Once logged in NIS is also able to serve
a group map to authorize the users to different unix groups.
I haven't used LDAP myself for these purposes but think that you can do
the same with LDAP.
You can definitely do that with LDAP - I did not know you could
also do it with NIS. Thanks.
Steve555
2019-06-18 17:26:13 UTC
Permalink
Post by Clark Smith
Post by Henrik Carlqvist
Post by Clark Smith
Post by K Venken
Would nss_ldap be a solution? Otherwise, NIS is still available.
Isn't that for authorization, rather than authentication? I was
under the impression that the NSS stuff (NIS being one of the backends
that NSS can use) kicks in after a given user has been successfully
authenticated.
NIS is able to serve a passwd map to NIS clients which will use that map
to authenticate users at login. Once logged in NIS is also able to serve
a group map to authorize the users to different unix groups.
I haven't used LDAP myself for these purposes but think that you can do
the same with LDAP.
You can definitely do that with LDAP - I did not know you could
also do it with NIS. Thanks.
I actually worked on a system that did somethilng like this with LDAP.
The user authenticated to the ldap server and got given back a token that
encoded a time-to-live and a bitfield that provided their authorisation
level (users could be 'status', 'user', 'admin', etc). The ldap
server was wrappered by some java technology and the exchange between
the linux system and the ldap server was by xml SOAP documents.
So the user sent a request soap doc with his id and credentials,
and got back a token that encoded the auth rights and a time-to-live;
after the TTL expires he has to renew the token.

However, we wrote a custom system on the linux machine that recognised the
tokens and performed the appropriate checks to facilitate user logins.
So this is certainly not a standard part of linux. But hopefully this gives
some idea of how such a system can work.

It can be a very powerful approach, in that a set of users can be managed
from a central ldap database, and their access to a large number of
machines controlled in this way; it's really what used to be called
"enterprise" level tech.
--
Gnd -|o----|- Vcc Hey computer, what's the weather in Sydney?
trig -| 555 |- dschrg $> finger o:***@graph.no|tail -1|espeak
o/p -| |- thrsh
rst -|-----|- cntrl Steve555
Henrik Carlqvist
2019-06-19 05:50:25 UTC
Permalink
Post by Steve555
I actually worked on a system that did somethilng like this with LDAP.
The user authenticated to the ldap server and got given back a token
that encoded a time-to-live and a bitfield that provided their
authorisation level (users could be 'status', 'user', 'admin', etc).
The ldap server was wrappered by some java technology and the exchange
between the linux system and the ldap server was by xml SOAP documents.
So the user sent a request soap doc with his id and credentials,
and got back a token that encoded the auth rights and a time-to-live;
after the TTL expires he has to renew the token.
To me that sounds like some kind of single sign on solution were a web
server is able to identify visitors using the same database which the
workstations use for console logins. Was your application for a web
server?

regards Henrik
Steve555
2019-06-19 14:20:43 UTC
Permalink
Post by Henrik Carlqvist
Post by Steve555
I actually worked on a system that did somethilng like this with LDAP.
The user authenticated to the ldap server and got given back a token
that encoded a time-to-live and a bitfield that provided their
authorisation level (users could be 'status', 'user', 'admin', etc).
The ldap server was wrappered by some java technology and the exchange
between the linux system and the ldap server was by xml SOAP documents.
So the user sent a request soap doc with his id and credentials,
and got back a token that encoded the auth rights and a time-to-live;
after the TTL expires he has to renew the token.
To me that sounds like some kind of single sign on solution were a web
server is able to identify visitors using the same database which the
workstations use for console logins. Was your application for a web
server?
regards Henrik
It was for centrally controlled sign-in, basically for large numbers of
servers in farms, that were configured to do specialised processing tasks.
The customer wanted to be able to control a population of users from a single
point, which was the ldap admin. Once a user was configured in ldap, if he
attempts to log in to any server, the software automatically re-sends the login
request to the ldap server, gets the response certificate, and then allows the
login to proceed with the returned access rights. The login path into the
linux server uses custom-written code, not the standard linux login.
The user can request a new login at any time by re-submitting his existing
certificate (before it expires), or establish a new login by submitting
credentials again. It had some similarities to
esso: https://www.oneidentity.com/products/esso/ but was developed in-house
at the company I was working at. Actually a very interesting project :-)
--
Gnd -|o----|- Vcc Hey computer, what's the weather in Sydney?
trig -| 555 |- dschrg $> finger o:***@graph.no|tail -1|espeak
o/p -| |- thrsh
rst -|-----|- cntrl Steve555
Steve555
2019-06-19 14:53:19 UTC
Permalink
Post by Steve555
Post by Henrik Carlqvist
Post by Steve555
I actually worked on a system that did somethilng like this with LDAP.
The user authenticated to the ldap server and got given back a token
that encoded a time-to-live and a bitfield that provided their
authorisation level (users could be 'status', 'user', 'admin', etc).
The ldap server was wrappered by some java technology and the exchange
between the linux system and the ldap server was by xml SOAP documents.
So the user sent a request soap doc with his id and credentials,
and got back a token that encoded the auth rights and a time-to-live;
after the TTL expires he has to renew the token.
To me that sounds like some kind of single sign on solution were a web
server is able to identify visitors using the same database which the
workstations use for console logins. Was your application for a web
server?
regards Henrik
It was for centrally controlled sign-in, basically for large numbers of
servers in farms, that were configured to do specialised processing tasks.
The customer wanted to be able to control a population of users from a single
point, which was the ldap admin. Once a user was configured in ldap, if he
attempts to log in to any server, the software automatically re-sends the
request to the ldap server, gets the response certificate, and then allows
login to proceed with the returned access rights. The login path into the
linux server uses custom-written code, not the standard linux login.
The user can request a new login at any time by re-submitting his existing
certificate (before it expires), or establish a new login by submitting
credentials again. It had some similarities to
esso: https://www.oneidentity.com/products/esso/ but was developed in-house
at the company I was working at. Actually a very interesting project :-)
I should probably add the login route to each server was ssh... no console
login. The servers were usually remote from the users.
--
Gnd -|o----|- Vcc Hey computer, what's the weather in Sydney?
trig -| 555 |- dschrg $> finger o:***@graph.no|tail -1|espeak
o/p -| |- thrsh
rst -|-----|- cntrl Steve555
Loading...