How about to authenticate without OS account?
Victor wanted database-only user authentication on IDS 11.70 (SLES 11) without PAM/LDAP: a single surrogate OS account connects, then a DBA stored procedure validates credentials and issues SET SESSION AUTHORIZATION to switch to the real db_user. This worked for local access, but any remote (cross-server) query then failed with error -32504, "Operations on remote objects are not allowed after session level set." Jonathan Leffler noted IDS always requires external authentication and knew no workaround; Fernando suggested OS-level LDAP authentication (transparent to Informix) and thought a 11.7 trusted context might avoid -32504, but Victor tried a trusted context and got the same error. No resolution is recorded.
Auto-generated by DrWatson from the posts below — may be imperfect; read the full thread.
How to implement authentication without OS accounts?
Hello
I have a question about the authentication of users.
Database: Informix 11.70FC1
Operating System: SUSE SLES 11.1
Preconditions:
- Users must be identified fully via informix
- acceptably creating a surrogate system user
- PAM, LDAP and any external authentication are not allowed
- Users should be able to perform remote queries.
I made the following:
1. Has been created a surrogate system user
# cat /etc/passwd | grep surrogate_user
surrogate_user:x:1002:100::/home/ surrogate_user:/bin/false
2. Has been created following database schema:
grant connect to surrogate_user;> permission granted
grant connect to db_user;> permission granted
grant setsessionauth on db_user to surrogate_user;> permission granted
create dba procedure set_auth(p_username char(20), p_password char(20))
define sql_str char(100);
-- ...
-- checking the validity of given user
-- ...
let sql_str = "set session authorization to '" || trim(p_username) || "'";
execute immediate sql_str;
end procedure;
> routine created
grant execute on procedure set_auth(char) to 'surrogate_user';> permission granted
3. Then the surrogate_user connected to the server and performed the following
sql-commands:
select user from table(set{1});> surrogate_user
execute procedure set_auth("db_user", "db_user_passwd");> routine executed
select user from table(set{1});> db_user
4. It would seem that everything ended well, we were able to create own
authentication system, but then come the problems. Any remote query results in
an error: -32504 Operations on remote objects are not allowed after session
level set.
Are there any tricks that will help?
Best regards
Victor
On Tue, Jan 18, 2011 at 08:25, VICTOR VAT <victor16@inbox.ru> wrote:
> How to implement authentication without OS accounts?
>
> Hello
>
> I have a question about the authentication of users.
>
> Database: Informix 11.70FC1
> Operating System: SUSE SLES 11.1
>
> Preconditions:
> - Users must be identified fully via informix
> - acceptably creating a surrogate system user
> - PAM, LDAP and any external authentication are not allowed
>
So - this condition rules out anything that is currently available.
Stay tuned - but as of 2011-01-01 and 11.70.xC1, you have just stated that
you cannot use IDS.
IDS currently requires external authentication - via the system password
file or via PAM (and hence to LDAP, MSAD, or whatever).
> - Users should be able to perform remote queries.
>
> I made the following:
>
> 1. Has been created a surrogate system user
>
> # cat /etc/passwd | grep surrogate_user>
> surrogate_user:x:1002:100::/home/ surrogate_user:/bin/false
>
OK - this is a real o/s user, with a password in, presumably, the shadow
password file.
> 2. Has been created following database schema:
>
> grant connect to surrogate_user;> > permission granted
>
> grant connect to db_user;> > permission granted
>
> grant setsessionauth on db_user to surrogate_user;> > permission granted
>
Phew! Well, I suppose so...but I would worry about the security of your
surrogate_user account - a lot!
> create dba procedure set_auth(p_username char(20), p_password char(20))>
> define sql_str char(100);
>
> -- ...
> -- checking the validity of given user
> -- ...
>
> let sql_str = "set session authorization to '" || trim(p_username) || "'";
> execute immediate sql_str;
>
> end procedure;
> > routine created
>
Which user created this procedure? 'informix'? 'surrogate_user'? Looks
like it is probably 'informix'.
> grant execute on procedure set_auth(char) to 'surrogate_user';> > permission granted
>
> 3. Then the surrogate_user connected to the server and performed the
> following
> sql-commands:
>
> select user from table(set{1});> > surrogate_user
>
execute procedure set_auth("db_user", "db_user_passwd");> > routine executed
>
> select user from table(set{1});> > db_user
>
OK. Anyone who connects as surrogate_user can 'become' db_user.
> 4. It would seem that everything ended well, we were able to create own
> authentication system, but then come the problems. Any remote query results
> in
> an error: -32504 Operations on remote objects are not allowed after session
> level set.
>
That's an interesting error, somewhat subverting the system.
> Are there any tricks that will help?
>
Probably not yet. I wasn't aware of -32504.
--
Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
"Blessed are we who can laugh at ourselves, for we shall never cease to be
amused."
--485b393aafa57d1f31049a21edf7
See below
Tue, 18 Jan 2011 12:07:22 -0500 (EST)
письмо от "Jonathan Leffler"
<jonathan.leffler@gmail.com>:
> On Tue, Jan 18, 2011 at 08:25, VICTOR VAT <victor16@inbox.ru> wrote:
>
> > How to implement authentication without OS accounts?
> >
> > Hello
> >
> > I have a question about the authentication of users.
> >
> > Database: Informix 11.70FC1
> > Operating System: SUSE SLES 11.1
> >
> > Preconditions:
> > - Users must be identified fully via informix
> > - acceptably creating a surrogate system user
> > - PAM, LDAP and any external authentication are not allowed
> >
>
> So - this condition rules out anything that is currently available.
> Stay tuned - but as of 2011-01-01 and 11.70.xC1, you have just stated that
> you cannot use IDS.
> IDS currently requires external authentication - via the system password
> file or via PAM (and hence to LDAP, MSAD, or whatever).
That's condition rule - because the clients use .NET and C++ libraries.
As far as I know currently there is no mechanism
for the implementation of external authentication for C# and C++.
>
> > - Users should be able to perform remote queries.
> >
> > I made the following:
> >
> > 1. Has been created a surrogate system user
> >
> > # cat /etc/passwd | grep surrogate_user> >
> > surrogate_user:x:1002:100::/home/ surrogate_user:/bin/false
> >
>
> OK - this is a real o/s user, with a password in, presumably, the shadow
> password file.
Yes, it's real o/s user, and it has own password, stored at /etc/shadow.
This is the common configuration.
>
> > 2. Has been created following database schema:
> >
> > grant connect to surrogate_user;> > > permission granted
> >
> > grant connect to db_user;> > > permission granted
> >
> > grant setsessionauth on db_user to surrogate_user;> > > permission granted
> >
>
> Phew! Well, I suppose so...but I would worry about the security of your
> surrogate_user account - a lot!
Yes, of course, this is the weakest link in the configuration.
But the surrogate_user is very limited. It has no a shell, it has no home
directory, it can connect via the dedicated port only. With regard to
the database, it's rights is very limited also . He has connect
permission and allowed to execute a procedure set_auth() only.
>
> > create dba procedure set_auth(p_username char(20), p_password char(20))> >
> > define sql_str char(100);
> >
> > -- ...
> > -- checking the validity of given user
> > -- ...
> >
> > let sql_str = "set session authorization to '" || trim(p_username) || "'";
> > execute immediate sql_str;
> >
> > end procedure;
> > > routine created
> >
>
> Which user created this procedure? 'informix'? 'surrogate_user'? Looks
> like it is probably 'informix'.
All the above was created by informix.
>
> > grant execute on procedure set_auth(char) to 'surrogate_user';> > > permission granted
> >
>
> > 3. Then the surrogate_user connected to the server and performed the
> > following
> > sql-commands:
> >
> > select user from table(set{1});> > > surrogate_user
> >
>
> execute procedure set_auth("db_user", "db_user_passwd");> > > routine executed
> >
> > select user from table(set{1});> > > db_user
> >
>
> OK. Anyone who connects as surrogate_user can 'become' db_user.
Not exactly. It must know db_user credentials also.
In the example, the simplest method of authentication was shown.
Of course, instead of a password, I can use any type of data,
for example, BLOB, and pass binary certificate for verification purpose.
For example, I can realize set_auth("db_user",filetoblob(...)) and check
it using C-UDR.
>
> > 4. It would seem that everything ended well, we were able to create own
> > authentication system, but then come the problems. Any remote query results
> > in
> > an error: -32504 Operations on remote objects are not allowed after session
> > level set.
> >
>
> That's an interesting error, somewhat subverting the system.
>
> > Are there any tricks that will help?
> >
>
> Probably not yet. I wasn't aware of -32504.
It's a pity. I would prefer not to use the accounts of the operating system.
This is very tiring to input users data on all cluster nodes :)
>
> --
> Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
> Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
> "Blessed are we who can laugh at ourselves, for we shall never cease to be
> amused."
>
> --485b393aafa57d1f31049a21edf7
>
>
>
I'm sorry if my post contains wrong assumptions. I didn't read previous
posts with enough attention...
Just a few points:
- Configure the hosts to authenticate externaly (LDAP). It will be
transparent for Informix and the users will be created in just one place
- I'm under the impression that -32504 does not happen when you use trusted
context (new feature in IDS 11.7). This could help you, but needs
validation.
Regards.
On Tue, Jan 18, 2011 at 7:10 PM, VICTOR VAT <victor16@inbox.ru> wrote:
> See below
>
> Tue, 18 Jan 2011 12:07:22 -0500 (EST)
> письмо от "Jonathan
> Leffler"
> <jonathan.leffler@gmail.com>:
>
> > On Tue, Jan 18, 2011 at 08:25, VICTOR VAT <victor16@inbox.ru> wrote:
> >
> > > How to implement authentication without OS accounts?
> > >
> > > Hello
> > >
> > > I have a question about the authentication of users.
> > >
> > > Database: Informix 11.70FC1
> > > Operating System: SUSE SLES 11.1
> > >
> > > Preconditions:
> > > - Users must be identified fully via informix
> > > - acceptably creating a surrogate system user
> > > - PAM, LDAP and any external authentication are not allowed
> > >
> >
> > So - this condition rules out anything that is currently available.
> > Stay tuned - but as of 2011-01-01 and 11.70.xC1, you have just stated
> that
> > you cannot use IDS.
> > IDS currently requires external authentication - via the system password
> > file or via PAM (and hence to LDAP, MSAD, or whatever).
>
> That's condition rule - because the clients use .NET and C++ libraries.
> As far as I know currently there is no mechanism
> for the implementation of external authentication for C# and C++.
>
> >
> > > - Users should be able to perform remote queries.
> > >
> > > I made the following:
> > >
> > > 1. Has been created a surrogate system user
> > >
> > > # cat /etc/passwd | grep surrogate_user> > >
> > > surrogate_user:x:1002:100::/home/ surrogate_user:/bin/false
> > >
> >
> > OK - this is a real o/s user, with a password in, presumably, the shadow
> > password file.
>
> Yes, it's real o/s user, and it has own password, stored at /etc/shadow.
> This is the common configuration.
>
> >
> > > 2. Has been created following database schema:
> > >
> > > grant connect to surrogate_user;> > > > permission granted
> > >
> > > grant connect to db_user;> > > > permission granted
> > >
> > > grant setsessionauth on db_user to surrogate_user;> > > > permission granted
> > >
> >
> > Phew! Well, I suppose so...but I would worry about the security of your
> > surrogate_user account - a lot!
>
> Yes, of course, this is the weakest link in the configuration.
> But the surrogate_user is very limited. It has no a shell, it has no home
> directory, it can connect via the dedicated port only. With regard to
> the database, it's rights is very limited also . He has connect
> permission and allowed to execute a procedure set_auth() only.
>
> >
> > > create dba procedure set_auth(p_username char(20), p_password char(20))> > >
> > > define sql_str char(100);
> > >
> > > -- ...
> > > -- checking the validity of given user
> > > -- ...
> > >
> > > let sql_str = "set session authorization to '" || trim(p_username) ||
> "'";
> > > execute immediate sql_str;
> > >
> > > end procedure;
> > > > routine created
> > >
> >
> > Which user created this procedure? 'informix'? 'surrogate_user'? Looks
> > like it is probably 'informix'.
>
> All the above was created by informix.
>
> >
> > > grant execute on procedure set_auth(char) to 'surrogate_user';> > > > permission granted
> > >
> >
> > > 3. Then the surrogate_user connected to the server and performed the
> > > following
> > > sql-commands:
> > >
> > > select user from table(set{1});> > > > surrogate_user
> > >
> >
> > execute procedure set_auth("db_user", "db_user_passwd");> > > > routine executed
> > >
> > > select user from table(set{1});> > > > db_user
> > >
> >
> > OK. Anyone who connects as surrogate_user can 'become' db_user.
>
> Not exactly. It must know db_user credentials also.
> In the example, the simplest method of authentication was shown.
> Of course, instead of a password, I can use any type of data,
> for example, BLOB, and pass binary certificate for verification purpose.
> For example, I can realize set_auth("db_user",filetoblob(...)) and check
> it using C-UDR.
>
> >
> > > 4. It would seem that everything ended well, we were able to create own
> > > authentication system, but then come the problems. Any remote query
> results
> > > in
> > > an error: -32504 Operations on remote objects are not allowed after
> session
> > > level set.
> > >
> >
> > That's an interesting error, somewhat subverting the system.
> >
> > > Are there any tricks that will help?
> > >
> >
> > Probably not yet. I wasn't aware of -32504.
>
> It's a pity. I would prefer not to use the accounts of the operating
> system.
> This is very tiring to input users data on all cluster nodes :)
>
> >
> > --
> > Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
> > Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
> > "Blessed are we who can laugh at ourselves, for we shall never cease to
> be
> > amused."
> >
> > --485b393aafa57d1f31049a21edf7
> >
> >
> >
>
>
>
>
*******************************************************************************
> Forum Note: Use "Reply" to post a response in the discussion forum.
>
>
--
Fernando Nunes
Portugal
http://informix-technology.blogspot.com
My email works... but I don't check it frequently...
--0015174c104ee27a6d049a28b917
Fernando, thank you for your advices but apparently it does not help.
See below
Tue, 18 Jan 2011 20:13:41 -0500 (EST)
письмо от "Fernando Nunes"
<domusonline@gmail.com>:
> I'm sorry if my post contains wrong assumptions. I didn't read previous
> posts with enough attention...
> Just a few points:
>
> - Configure the hosts to authenticate externaly (LDAP). It will be
> transparent for Informix and the users will be created in just one place
We cannot use LDAP, because most of clients connects via .NET and C++.
As far as I now currently there is no possibility to connect to Informix
databases using LDAP and .NET (or C++) simultaneously.
> - I'm under the impression that -32504 does not happen when you use trusted
> context (new feature in IDS 11.7). This could help you, but needs
> validation.
I created trusted context
CREATE TRUSTED CONTEXT db_user_ctx
USER surrogate_user
ATTRIBUTES ( ADDRESS '' WITH ENCRYPTION none)
NO DEFAULT ROLE
ENABLE
WITH USE FOR
db_user WITHOUT AUTHENTICATION
but the same error -32504 appeared
>
> Regards.
>
> On Tue, Jan 18, 2011 at 7:10 PM, VICTOR VAT <victor16@inbox.ru> wrote:
>
> > See below
> >
> > Tue, 18 Jan 2011 12:07:22 -0500 (EST)
> > письмо от "Jonathan
> > Leffler"
> > <jonathan.leffler@gmail.com>:
> >
> > > On Tue, Jan 18, 2011 at 08:25, VICTOR VAT <victor16@inbox.ru> wrote:
> > >
> > > > How to implement authentication without OS accounts?
> > > >
> > > > Hello
> > > >
> > > > I have a question about the authentication of users.
> > > >
> > > > Database: Informix 11.70FC1
> > > > Operating System: SUSE SLES 11.1
> > > >
> > > > Preconditions:
> > > > - Users must be identified fully via informix
> > > > - acceptably creating a surrogate system user
> > > > - PAM, LDAP and any external authentication are not allowed
> > > >
> > >
> > > So - this condition rules out anything that is currently available.
> > > Stay tuned - but as of 2011-01-01 and 11.70.xC1, you have just stated
> > that
> > > you cannot use IDS.
> > > IDS currently requires external authentication - via the system password
> > > file or via PAM (and hence to LDAP, MSAD, or whatever).
> >
> > That's condition rule - because the clients use .NET and C++ libraries.
> > As far as I know currently there is no mechanism
> > for the implementation of external authentication for C# and C++.
> >
> > >
> > > > - Users should be able to perform remote queries.
> > > >
> > > > I made the following:
> > > >
> > > > 1. Has been created a surrogate system user
> > > >
> > > > # cat /etc/passwd | grep surrogate_user> > > >
> > > > surrogate_user:x:1002:100::/home/ surrogate_user:/bin/false
> > > >
> > >
> > > OK - this is a real o/s user, with a password in, presumably, the shadow
> > > password file.
> >
> > Yes, it's real o/s user, and it has own password, stored at /etc/shadow.
> > This is the common configuration.
> >
> > >
> > > > 2. Has been created following database schema:
> > > >
> > > > grant connect to surrogate_user;> > > > > permission granted
> > > >
> > > > grant connect to db_user;> > > > > permission granted
> > > >
> > > > grant setsessionauth on db_user to surrogate_user;> > > > > permission granted
> > > >
> > >
> > > Phew! Well, I suppose so...but I would worry about the security of your
> > > surrogate_user account - a lot!
> >
> > Yes, of course, this is the weakest link in the configuration.
> > But the surrogate_user is very limited. It has no a shell, it has no home
> > directory, it can connect via the dedicated port only. With regard to
> > the database, it's rights is very limited also . He has connect
> > permission and allowed to execute a procedure set_auth() only.
> >
> > >
> > > > create dba procedure set_auth(p_username char(20), p_password char(20))> > > >
> > > > define sql_str char(100);
> > > >
> > > > -- ...
> > > > -- checking the validity of given user
> > > > -- ...
> > > >
> > > > let sql_str = "set session authorization to '" || trim(p_username) ||
> > "'";
> > > > execute immediate sql_str;
> > > >
> > > > end procedure;
> > > > > routine created
> > > >
> > >
> > > Which user created this procedure? 'informix'? 'surrogate_user'? Looks
> > > like it is probably 'informix'.
> >
> > All the above was created by informix.
> >
> > >
> > > > grant execute on procedure set_auth(char) to 'surrogate_user';> > > > > permission granted
> > > >
> > >
> > > > 3. Then the surrogate_user connected to the server and performed the
> > > > following
> > > > sql-commands:
> > > >
> > > > select user from table(set{1});> > > > > surrogate_user
> > > >
> > >
> > > execute procedure set_auth("db_user", "db_user_passwd");> > > > > routine executed
> > > >
> > > > select user from table(set{1});> > > > > db_user
> > > >
> > >
> > > OK. Anyone who connects as surrogate_user can 'become' db_user.
> >
> > Not exactly. It must know db_user credentials also.
> > In the example, the simplest method of authentication was shown.
> > Of course, instead of a password, I can use any type of data,
> > for example, BLOB, and pass binary certificate for verification purpose.
> > For example, I can realize set_auth("db_user",filetoblob(...)) and check
> > it using C-UDR.
> >
> > >
> > > > 4. It would seem that everything ended well, we were able to create own
> > > > authentication system, but then come the problems. Any remote query
> > results
> > > > in
> > > > an error: -32504 Operations on remote objects are not allowed after
> > session
> > > > level set.
> > > >
> > >
> > > That's an interesting error, somewhat subverting the system.
> > >
> > > > Are there any tricks that will help?
> > > >
> > >
> > > Probably not yet. I wasn't aware of -32504.
> >
> > It's a pity. I would prefer not to use the accounts of the operating
> > system.
> > This is very tiring to input users data on all cluster nodes :)
> >
> > >
> > > --
> > > Jonathan Leffler <jonathan.leffler@gmail.com> #include <disclaimer.h>
> > > Guardian of DBD::Informix - v2008.0513 - http://dbi.perl.org
> > > "Blessed are we who can laugh at ourselves, for we shall never cease to
> > be
> > > amused."
> > >
> > > --485b393aafa57d1f31049a21edf7
> > >
> > >
> > >
> >
> >
> >
> >
>
*******************************************************************************
> > Forum Note: Use "Reply" to post a response in the discussion forum.
> >
> >
>
> --
> Fernando Nunes
> Portugal
>
> http://informix-technology.blogspot.com
> My email works... but I don't check it frequently...
>
> --0015174c104ee27a6d049a28b917
>
>
>
*******************************************************************************
> Forum Note: Use "Reply@
When I mentioned LDAP. I meant to say that you can configure the OS to
authenticate through LDAP. Not Informix.
If the underlying OS is configured for LDAP (properly) it will be
transparent for Informix.
As for the error, I would need to check that... I was 99% it would work...
I'm under the impression that this was mentioned in an internal call.
I would need to verify where I got this idea... In any case, previous option
would still be valid I think.
Regards.
On Wed, Jan 19, 2011 at 6:12 AM, VICTOR VAT <victor16@inbox.ru> wrote:
> Fernando, thank you for your advices but apparently it does not help.
> See below
>
> Tue, 18 Jan 2011 20:13:41 -0500 (EST)
> письмо от "Fernando Nunes"
> <domusonline@gmail.com>:
>
> > I'm sorry if my post contains wrong assumptions. I didn't read previous
> > posts with enough attention...
> > Just a few points:
> >
> > - Configure the hosts to authenticate externaly (LDAP). It will be
> > transparent for Informix and the users will be created in just one place
>
> We cannot use LDAP, because most of clients connects via .NET and C++.
> As far as I now currently there is no possibility to connect to Informix
> databases using LDAP and .NET (or C++) simultaneously.
>
> > - I'm under the impression that -32504 does not happen when you use
> trusted
> > context (new feature in IDS 11.7). This could help you, but needs
> > validation.
>
> I created trusted context
>
> CREATE TRUSTED CONTEXT db_user_ctx
> USER surrogate_user
> ATTRIBUTES ( ADDRESS '' WITH ENCRYPTION none)
> NO DEFAULT ROLE
> ENABLE
> WITH USE FOR
> db_user WITHOUT AUTHENTICATION
>
> but the same error -32504 appeared
>
> >
> > Regards.
> >
> > On Tue, Jan 18, 2011 at 7:10 PM, VICTOR VAT <victor16@inbox.ru> wrote:
> >
> > > See below
> > >
> > > Tue, 18 Jan 2011 12:07:22 -0500 (EST)
> > > письмо от "Jonathan
> > > Leffler"
> > > <jonathan.leffler@gmail.com>:
> > >
> > > > On Tue, Jan 18, 2011 at 08:25, VICTOR VAT <victor16@inbox.ru> wrote:
> > > >
> > > > > How to implement authentication without OS accounts?
> > > > >
> > > > > Hello
> > > > >
> > > > > I have a question about the authentication of users.
> > > > >
> > > > > Database: Informix 11.70FC1
> > > > > Operating System: SUSE SLES 11.1
> > > > >
> > > > > Preconditions:
> > > > > - Users must be identified fully via informix
> > > > > - acceptably creating a surrogate system user
> > > > > - PAM, LDAP and any external authentication are not allowed
> > > > >
> > > >
> > > > So - this condition rules out anything that is currently available.
> > > > Stay tuned - but as of 2011-01-01 and 11.70.xC1, you have just stated
> > > that
> > > > you cannot use IDS.
> > > > IDS currently requires external authentication - via the system
> password
> > > > file or via PAM (and hence to LDAP, MSAD, or whatever).
> > >
> > > That's condition rule - because the clients use .NET and C++ libraries.
> > > As far as I know currently there is no mechanism
> > > for the implementation of external authentication for C# and C++.
> > >
> > > >
> > > > > - Users should be able to perform remote queries.
> > > > >
> > > > > I made the following:
> > > > >
> > > > > 1. Has been created a surrogate system user
> > > > >
> > > > > # cat /etc/passwd | grep surrogate_user> > > > >
> > > > > surrogate_user:x:1002:100::/home/ surrogate_user:/bin/false
> > > > >
> > > >
> > > > OK - this is a real o/s user, with a password in, presumably, the
> shadow
> > > > password file.
> > >
> > > Yes, it's real o/s user, and it has own password, stored at
> /etc/shadow.
> > > This is the common configuration.
> > >
> > > >
> > > > > 2. Has been created following database schema:
> > > > >
> > > > > grant connect to surrogate_user;> > > > > > permission granted
> > > > >
> > > > > grant connect to db_user;> > > > > > permission granted
> > > > >
> > > > > grant setsessionauth on db_user to surrogate_user;> > > > > > permission granted
> > > > >
> > > >
> > > > Phew! Well, I suppose so...but I would worry about the security of
> your
> > > > surrogate_user account - a lot!
> > >
> > > Yes, of course, this is the weakest link in the configuration.
> > > But the surrogate_user is very limited. It has no a shell, it has no
> home
> > > directory, it can connect via the dedicated port only. With regard to
> > > the database, it's rights is very limited also . He has connect
> > > permission and allowed to execute a procedure set_auth() only.
> > >
> > > >
> > > > > create dba procedure set_auth(p_username char(20), p_password
> char(20))> > > > >
> > > > > define sql_str char(100);
> > > > >
> > > > > -- ...
> > > > > -- checking the validity of given user
> > > > > -- ...
> > > > >
> > > > > let sql_str = "set session authorization to '" || trim(p_username)
> ||
> > > "'";
> > > > > execute immediate sql_str;
> > > > >
> > > > > end procedure;
> > > > > > routine created
> > > > >
> > > >
> > > > Which user created this procedure? 'informix'? 'surrogate_user'?
> Looks
> > > > like it is probably 'informix'.
> > >
> > > All the above was created by informix.
> > >
> > > >
> > > > > grant execute on procedure set_auth(char) to 'surrogate_user';> > > > > > permission granted
> > > > >
> > > >
> > > > > 3. Then the surrogate_user connected to the server and performed
> the
> > > > > following
> > > > > sql-commands:
> > > > >
> > > > > select user from table(set{1});> > > > > > surrogate_user
> > > > >
> > > >
> > > > execute procedure set_auth("db_user", "db_user_passwd");> > > > > > routine executed
> > > > >
> > > > > select user from table(set{1});> > > > > > db_user
> > > > >
> > > >
> > > > OK. Anyone who connects as surrogate_user can 'become' db_user.
> > >
> > > Not exactly. It must know db_user credentials also.
> > > In the example, the simplest method of authentication was shown.
> > > Of course, instead of a password, I can use any type of data,
> > > for example, BLOB, and pass binary certificate for verification
> purpose.
> > > For example, I can realize set_auth("db_user",filetoblob(...)) and
> check
> > > it using C-UDR.
> > >
> > > >
> > > > > 4. It would seem that everything ended well, we were able to create
> own
> > > > > authentication system, but then come the problems. Any remote query
> > > results
> > > > > in
> > > > > an error: -32504 Operations on remote objects are not allowed after
> > > session
> > > > > level set.
> > > > >
> > > >
> > > > That's an interesting error, somewhat subverting the system.
> > > >
> > > > > Are there any tricks that will help?
> > > > >
> > > >
> > > > Probably not yet. I wasn't aware of -32504.
> > >
> > > It's a pity. I would prefer not to use the accounts of the operating
> > > system