When specifying USER trust levels, you can specify any trust level (0 -
5), so they won't always have trust level 5. For example:
TRUST LEVEL 5 USER j...@company.com USER j...@company.com
TRUST LEVEL 0 USER bad...@company.com
TRUST LEVEL 3 USER *...@company.com
TRUST LEVEL 4 USER SampleAuth://*...@company.com
TRUST LEVEL 1 USER *://*
Thanks,
David
David Bender
STAF/STAX Development
IBM Software Group, WPLC
11501 Burnet Rd.
Bldg. 903-5B002
Austin, TX 78758-3400
Phone (T/L): 1-512-286-5315 (363-5315)
ITN: 23635315
Email: bda...@us.ibm.com
"jander...@talentex.co.uk" <jander...@talentex.co.uk>
09/07/2009 02:25 AM
To
staf <staf-users@lists.sourceforge.net>
cc
Subject
Re: [staf-users] Authenticator on local and remote
Hi Sharon,
Sorry for not getting back to you before - yes, I had left out the bit
where I return the encrypted credentials from AUTHENTICATE. Thank you
for helping.
This leads me to another question - I have my people working in a large
network. The will log on to a number of servers, all of which will be
running staf services; I want to use user level trust to control what
they can do, but it seems that any user can do anything on the server
they aer logged on to, since they will have trust level 5. Is there a
way around this?
/jan
Sharon Lucas wrote:
> Jan,
>
> I suspect that you did something wrong in the authenticator that you
> wrote. But, I also think there's a bug in STAFHandleManager where it
> should be returning RC 53 (Handle Authentication Denied) instead of RC 7
> (Invalid Request String) in this situation.
>
> First, make sure that you have your authenticator registered on the
remote
> and local machine as the same name. And, if you have a user properties
> file (or something like this that contains user ids and passwords), it
> must be available on both the remote and local machine.
>
> When an authenicated handle submits a remote STAF service request,
> STAFProc calls STAFHandleManager's authenticate() method (see source
code
> in src/staf/stafproc/STAFHandleManager.cpp) passing the authentication
> data that is provided under the covers via the STAF request. The
> STAFHandleManager::authenticate() method submits an AUTHENTICATE request
> to the Authenticator service to re-authenticate (if the authentication
> data isn't already cached and hasn't changed) using the DATA option
> (instead of the CREDENTIALS option) to provide the authentication data
> passed to it. That is, the STAFHandleManager will submit a request like
> the following to the authenticator service on the remote machine:
>
> STAF local <AuthenticatorService> AUTHENTICATE USER <userIdentifier>
> DATA <authenticationData>
>
> So, your authenticator must support an AUTHENTICATE request with the
DATA
> option specified (in addition to supporting an AUTHENTICATE request with
> the CREDENTIALS option specfied). If the DATA option is specified, then
> your authenticator should verify that the authentication data provided
is
> valid.
>
> When your authenticator handles an AUTHENTICATE request with the
> CREDENTIALS option specified, if the authentication is successful, it
> should be returning the authentication data in the result. This
> authentication data could be the actual credentials (e.g. the password),
> which is what the sample authenticator does, or it could be encrypted
> credentials (if your authenticator wanted to implement this). The
> STAFHandleManager caches this authentication data so it can use it for
> subsequent authentication requests.
>
> So, my guess is that your authenticator is not setting the result to the
> authentication data when handing an AUTHENTICATE request with the
> CREDENTIALS option specified. See the sample authenticator's
> handleAuthenticate() method for an example. Some of the code from this
> method is shown below. See the line in blue which sets the result to
the
> credentials value, as it uses the credentials value (e.g. the password)
> for the authentication data.
>
> STAFResult result = new STAFResult(STAFResult.Ok, "");
>
> ...
>
> // Get the CREDENTIALS or DATA option value
>
> if (parsedRequest.optionTimes("CREDENTIALS") != 0)
> credentialsValue = parsedRequest.optionValue("credentials");
> else
> dataValue = parsedRequest.optionValue("data");
>
> // If CREDENTIALS specified, verify match in fUserProperties
> if (parsedRequest.optionTimes("CREDENTIALS") != 0)
> {
> if (fUserProperties.getProperty(userValue) == null)
> {
> return new STAFResult(
> STAFResult.HandleAuthenticationDenied,
> "User " + userValue + " is not a valid user");
> }
> else if (!(fUserProperties.getProperty(userValue)).equals(
> credentialsValue))
> {
> return new STAFResult(
> STAFResult.HandleAuthenticationDenied,
> "Invalid credentials for user " + userValue);
> }
> else
> {
> // Authenticated successfully.
>
> // XXX: Could "encrypt" the credentials and return and
> // store the encrypted credentials as the authentication
> // data instead of returning the actual credentials.
>
> result.result = credentialsValue;
> }
> }
> else
> { // DATA specified, so verify match in fUserProperties
>
> // XXX: If encrypted the credentials, would verify match
with
> // encrypted credentials instead.
>
> if (fUserProperties.getProperty(userValue) == null)
> {
> return new STAFResult(
> STAFResult.HandleAuthenticationDenied,
> "User " + userValue + " is not a valid user");
> }
> else if (!(fUserProperties.getProperty(userValue)).equals(
> dataValue))
> {
> return new STAFResult(
> STAFResult.HandleAuthenticationDenied,
> "Invalid data for user " + userValue);
> }
> }
>
> However, this brings up a good point. STAFHandleManager is submitting
an
> AUTHENTICATE request to your authenticator with a blank value for the
DATA
> option. Since the DATA option requires a value, the AUTHENTICATE
request
> submitted by the STAFHandleManager is returning RC 7 (Invalid Request
> String). But, I think an authentication failure return code, RC 53
> (Handle Authentication Denied) should be returned instead of RC 7. To
> make this happen we should change STAFHandleManager::authenticate() to
> "wrap" the DATA option's value in STAF's colonLengthColon format, so
that
> the DATA option would have had a blank value instead of no value. We
> should also make a similar change to "wrap" the CREDENTIAL and USER
option
> values to avoid the RC 7. For example, we should make the following
> change at line 1003 in stafproc/STAFHandleManager.cpp:
>
> request += " DATA " + authenticationData;
>
> to:
>
> request += " DATA " + STAFHandle::wrapData(authenticationData);
>
> so that the following AUTHENTICATE request is submitted:
>
> STAF local <AuthenticatorService> AUTHENTICATE USER <userIdentifier>
> DATA :0:
>
> instead of:
>
> STAF local <AuthenticatorService> AUTHENTICATE USER <userIdentifier>
> DATA
>
> Please open a bug via http://staf.sourceforge.net called something like
> "RC 7 when authenticator returns blank authentication data". Or, let
me
> know if you prefer I open a bug for you.
>
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008
30-Day
trial. Simplify your report design, integration and deployment - and focus
on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
staf-users mailing list
staf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/staf-users
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day
trial. Simplify your report design, integration and deployment - and focus on
what you do best, core application coding. Discover what's new with
Crystal Reports now. http://p.sf.net/sfu/bobj-july
_______________________________________________
staf-users mailing list
staf-users@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/staf-users
