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.

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.

I think this is what you are looking for: https://bugzilla.redhat.com/show_bug.cgi?id=1145234

(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.

(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

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.

(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.

(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.

(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.

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.

(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.

(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.

(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.