Bug 1249485 - [AAA][PYTHON-SDK] 401 http status received when using kerberos at server side
[AAA][PYTHON-SDK] 401 http status received when using kerberos at server side
Status: CLOSED NEXTRELEASE
Product: Red Hat Enterprise Virtualization Manager
Classification: Red Hat
Component: ovirt-engine-sdk (Show other bugs)
3.5.1
Unspecified Unspecified
unspecified Severity unspecified
: ---
: 3.6.0
Assigned To: Ori Liel
Ondra Machacek
infra
: SupportQuestion
Depends On: 1145234
Blocks:
  Show dependency treegraph
 
Reported: 2015-08-03 03:39 EDT by Pavel Zhukov
Modified: 2016-02-10 14:27 EST (History)
11 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-08-04 03:03:07 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: Infra
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Pavel Zhukov 2015-08-03 03:39:12 EDT
Description of problem:
If AAA provider is in use PythonSDK looses authentication 
Not sure if it's known limitation

Version-Release number of selected component (if applicable):
rhevm-3.5.1.1-0.1.el6ev.noarch
ovirt-engine-extension-aaa-misc-1.0.0-2.el6ev.noarch

How reproducible:
100%

Steps to Reproduce:
1.  api = API (url = "https://rhevm.example.com", username = 'aaa', password = 'bbb', ca_file = '/etc/pki/ovirt-engine/ca.pem')
2. api.hosts.list()


Actual results:
Login successful (API constructor doesn't raise any exceptions and we see: 
2015-08-03 09:31:54,469 INFO  [org.ovirt.engine.core.dal.dbbroker.auditloghandling.AuditLogDirector] (ajp-/127.0.0.1:8702-10) Correlation ID: null, Call Stack: null, Custom Event ID: -1, Message: User aaa@EXAMPLE.COM@example.com-http logged in.

But next call is failed with
status: 401
reason: Authorization Required
detail: 
<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">
<html><head>
<title>401 Authorization Required</title>
</head><body>
<h1>Authorization Required</h1>
<p>This server could not verify that you
are authorized to access the document
requested.  Either you supplied the wrong
credentials (e.g., bad password), or your
browser doesn't understand how to supply
the credentials required.</p>
<hr>
<address>Apache/2.2.

Additional info:
REST API works fine
Comment 1 Alon Bar-Lev 2015-08-03 03:47:49 EDT
Not sure I follow, have you setup kerberos authentication? if so, you should not specify user and password, as the kerberos is the method to do so and set kerberos=True when constructing the api.
Comment 2 Oved Ourfali 2015-08-03 03:52:13 EDT
Please also attach the logs of your environment.
The REST-API and the SDK are equivalent. As far as I know, the SDK re-login on every request, unless you choose to work with sessions.

I don't think this is AAA related.
Setting the component accordingly.

Anyway, doesn't sound like a backend issue either. Setting component to SDK for examination.
Comment 3 Ondra Machacek 2015-08-03 05:03:17 EDT
I think this is what you are looking for: https://bugzilla.redhat.com/show_bug.cgi?id=1145234
Comment 4 Pavel Zhukov 2015-08-03 07:59:23 EDT
(In reply to Oved Ourfali from comment #2)
> Please also attach the logs of your environment.
> The REST-API and the SDK are equivalent. As far as I know, the SDK re-login
> on every request, unless you choose to work with sessions.
Not really. For REST-API curl passes Authentification header every time. But SDK use persist connection.

> As far as I know, the SDK re-login
> on every request, unless you choose to work with sessions.
By default it's 
# persistent_auth=True
and it doesn't.

        # We need to remember if persistent auth is enabled:
        context.manager[self.id].add(
            'persistent_auth',
             persistent_auth,
             Mode.R,
             typ=types.BooleanType
        )


> 
> I don't think this is AAA related.
> Setting the component accordingly.
> 
> Anyway, doesn't sound like a backend issue either. Setting component to SDK
> for examination.
Comment 5 Pavel Zhukov 2015-08-03 08:02:45 EDT
(In reply to Alon Bar-Lev from comment #1)
> Not sure I follow, have you setup kerberos authentication? if so, you should
> not specify user and password, as the kerberos is the method to do so and
> set kerberos=True when constructing the api.
I have

> if so, you should
> not specify user and password, as the kerberos is the method to do so and
> set kerberos=True when constructing the api.
I don't think this will work...
def __init__(self, url, username, password, key_file=None, cert_file=None,     ca_file=None, port=None, timeout=None, session_timeout=None, persistent_auth=True,renew_session=False, insecure=False, validate_cert_chain=True, filter=False, debug=False):  # @ReservedAssignment
Comment 6 Alon Bar-Lev 2015-08-03 08:08:25 EDT
kerberos is one barrier, you must pass it regardless of the cookie mechanism you use, this will be fixed when we introduce external signon mechanism (OAuth2 like).

if you use kerberos you must provide valid ticket for every request for apache to let you interact with application.

another option is to remove kerberos from api if you do not need it.

please close as notabug once you have it working.
Comment 7 Pavel Zhukov 2015-08-03 10:12:50 EDT
(In reply to Alon Bar-Lev from comment #6)
> kerberos is one barrier, you must pass it regardless of the cookie mechanism
> you use, this will be fixed when we introduce external signon mechanism
> (OAuth2 like).
> 
> if you use kerberos you must provide valid ticket for every request for
> apache to let you interact with application.
Alon, 
I checked using non-kerberos'd machine. The same issue.
if AAA is disabled - SDK works fine, if AAA is enabled  apache asks for basic authentification and api constructor can login (see log message in #1) but persisted_auth doesn't wotk.
> 
> another option is to remove kerberos from api if you do not need it.
Once again, There are NOT kerberos option in API. let's me remind We're talking about downstream/RHEV. 
> 
> please close as notabug once you have it working.
Comment 8 Alon Bar-Lev 2015-08-03 10:15:14 EDT
(In reply to Pavel Zhukov from comment #7)
> (In reply to Alon Bar-Lev from comment #6)
> > kerberos is one barrier, you must pass it regardless of the cookie mechanism
> > you use, this will be fixed when we introduce external signon mechanism
> > (OAuth2 like).
> > 
> > if you use kerberos you must provide valid ticket for every request for
> > apache to let you interact with application.
> Alon, 
> I checked using non-kerberos'd machine. The same issue.
> if AAA is disabled - SDK works fine, if AAA is enabled  apache asks for
> basic authentification and api constructor can login (see log message in #1)
> but persisted_auth doesn't wotk.

I do not understand what AAA is in this context, this is always "enabled" otherwise you cannot use the product.
Please elaborate.
Provide exact configuration.

When using restapi with standard configuration the jboss is requiring the basic authentication not apache.
Comment 9 Pavel Zhukov 2015-08-03 10:58:04 EDT
(In reply to Alon Bar-Lev from comment #8)
> (In reply to Pavel Zhukov from comment #7)
> > (In reply to Alon Bar-Lev from comment #6)
> > > kerberos is one barrier, you must pass it regardless of the cookie mechanism
> > > you use, this will be fixed when we introduce external signon mechanism
> > > (OAuth2 like).
> > > 
> > > if you use kerberos you must provide valid ticket for every request for
> > > apache to let you interact with application.
> > Alon, 
> > I checked using non-kerberos'd machine. The same issue.
> > if AAA is disabled - SDK works fine, if AAA is enabled  apache asks for
> > basic authentification and api constructor can login (see log message in #1)
> > but persisted_auth doesn't wotk.
> 
> I do not understand what AAA is in this context, this is always "enabled"
> otherwise you cannot use the product.
> Please elaborate.
> Provide exact configuration.
Probably I mixed terminology here. 

So I have rhev installation with aaa/kerberos (server side) configured and everything works fine (except know limitation like "Sign out" doesn't work etc).  REST-API works with curl (basic authentification, not GSSAPI) and my custom python script (which uses HTTPConnection as well btw and doesn't send auth every time). But PythonSDK doesn't work very well as per first comment.

Once I do these simple steps:
rm /etc/httpd/conf.d/auth_kerb*
rm -rf /etc/ovirt-engine/aaa/*
service httpd restart 
service ovirt-engine restart

PythonSDK starts to work without any issues with admin@internal user.

> 
> When using restapi with standard configuration the jboss is requiring the
> basic authentication not apache.
Comment 10 Alon Bar-Lev 2015-08-03 11:03:30 EDT
So again... if you configure kerberos you *MUST* pass httpd regardless of any special feature we have in ovirt, see comment#1.

You should pass kerberos=True instead of user and password in api constructor.

Either remove kerberos from api, or provide kerberos user with SuperUser role and use its credentials using keytab.

You should not pass password when using kerberos.
Comment 11 Pavel Zhukov 2015-08-04 02:52:23 EDT
(In reply to Alon Bar-Lev from comment #10)
> So again... if you configure kerberos you *MUST* pass httpd regardless of
> any special feature we have in ovirt, see comment#1.
> 
> You should pass kerberos=True instead of user and password in api
> constructor.
Alon, 
Please read  comments #3 and #5. There are NOT such argument in api constructor in released downstream (!) version. User/password arguments are mandatory in constructor.
Comment 12 Oved Ourfali 2015-08-04 03:03:07 EDT
(In reply to Pavel Zhukov from comment #11)
> (In reply to Alon Bar-Lev from comment #10)
> > So again... if you configure kerberos you *MUST* pass httpd regardless of
> > any special feature we have in ovirt, see comment#1.
> > 
> > You should pass kerberos=True instead of user and password in api
> > constructor.
> Alon, 
> Please read  comments #3 and #5. There are NOT such argument in api
> constructor in released downstream (!) version. User/password arguments are
> mandatory in constructor.

IIUC you're referring to 
The feature will be released as part of 3.6.0.
See Bug 1145234 - [RFE] PYTHON-SDK: Add support for Kerberos authentication.
Comment 13 Alon Bar-Lev 2015-08-04 03:23:32 EDT
(In reply to Oved Ourfali from comment #12)
> IIUC you're referring to 
> The feature will be released as part of 3.6.0.
> See Bug 1145234 - [RFE] PYTHON-SDK: Add support for Kerberos authentication.

hmmm... it should have been released for 3.5 with the kerberos release preview. so we actually state that sdk in 3.5 is unusable within this configuration.

Note You need to log in before you can comment on or make changes to this bug.