Bug 976716

Summary: FreeIPAs XMLRPC server returns a wrong Content-Type
Product: Red Hat Enterprise Linux 6 Reporter: Stephan Adig <stephan.adig>
Component: ipaAssignee: Martin Kosek <mkosek>
Status: CLOSED ERRATA QA Contact: Namita Soman <nsoman>
Severity: unspecified Docs Contact:
Priority: medium    
Version: 6.5CC: dpal, ksiddiqu, mkosek, pviktori, rcritten
Target Milestone: rc   
Target Release: ---   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: ipa-3.0.0-31.el6 Doc Type: Bug Fix
Doc Text:
Cause: Identity Management XML-RPC interface sometimes did not return correct Content-Type header in it's replies. Consequence: Programs or scripts processing the XML-RPC response may report validation error due and stop processing the response. Fix: XML-RPC responder was fixed to return correct Content-Type in reported situations. Result: Programs and scripts can call the Identity Management XML-RPC interface even with strict validation enabled.
Story Points: ---
Clone Of: Environment:
Last Closed: 2013-11-21 20:53:59 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Stephan Adig 2013-06-21 09:29:59 UTC
Description of problem:

I am trying to access the XMLRPC Server of FreeIPA via Rubies XMLRPC::Client.
This doesn't work, because the service itself sends out Content-Type: text/plain

which is wrong in terms of XMLRPC. Ruby itself has a strict sanity check in its XMLRPC Client, and throws an Exception when the returned Content-Type is not text/xml

Version-Release number of selected component (if applicable):
3.0.0-26.el6

How reproducible:

use XMLRPC::Client of Ruby 1.9 and some gssapi magic to send out the kerb authentication headers.


and use this code:

For example you can use this code:


require 'xmlrpc/client'
require 'base64'
require 'gssapi'

class FreeIPA
        attr_accessor :ipaurl
        attr_accessor :kerb_service

        def initialize(ipaurl,kerb_service='HTTP')
                uri=URI.parse ipaurl
                @ipaurl=ipaurl
                @kerb_service=kerb_service

                @ipa=XMLRPC::Client.new2(@ipaurl)
                @ipa.instance_variable_get(:@http).instance_variable_set(:@verify_mode, OpenSSL::SSL::VERIFY_NONE)

                @gsscli=GSSAPI::Simple.new(uri.host,@kerb_service)

                @token=

                @ipa.http_header_extra={
                        'Authorization'=>"Negotiate #{Base64.strict_encode64(@token)}",
                        'Referer' => @ipaurl,
                        'Content-Type' => 'text/xml; charset=utf-8',
                        'Accept' => 'text/plain'
                }
        end

        def user_list
                user_list=('user_find')
                user_list
        end
end



a=FreeIPA.new('<your ipa server url i.e. http://ipaurl/ipa/xml>','HTTP')
puts a.user_list


Steps to Reproduce:
1. adjust the ipa url in the script
2. kinit <kerb user which has write to admin IPA>
3. start the script

Actual results:
ruby kerb.rb 
/usr/lib/ruby/1.9.1/xmlrpc/client.rb:557:in `do_rpc': Wrong content-type (received 'text/plain' but expected 'text/xml') (RuntimeError)
	from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:420:in `call2'
	from /usr/lib/ruby/1.9.1/xmlrpc/client.rb:410:in `call'
	from kerb.rb:30:in `user_list'
	from kerb.rb:39:in `<main>'



Expected results:
ruby kerb.rb 
{"count"=>3, "truncated"=>false, "result"=>[{"dn"=>"uid=admin,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["admin"], "loginshell"=>["/bin/bash"], "uidnumber"=>["723200000"], "gidnumber"=>["723200000"], "has_password"=>true, "sn"=>["Administrator"], "homedirectory"=>["/home/admin"], "nsaccountlock"=>false}, {"dn"=>"uid=sadig,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["sadig"], "loginshell"=>["/bin/sh"], "uidnumber"=>["723200001"], "gidnumber"=>["723200001"], "has_password"=>true, "sn"=>["Adig"], "homedirectory"=>["/home/sadig"], "mail"=>["sadig.de"], "givenname"=>["Stephan"], "nsaccountlock"=>false}, {"dn"=>"uid=shermann,cn=users,cn=accounts,dc=intern,dc=sourcecode,dc=de", "has_keytab"=>true, "uid"=>["shermann"], "loginshell"=>["/bin/sh"], "uidnumber"=>["723200004"], "gidnumber"=>["723200004"], "has_password"=>true, "sn"=>["Adig"], "homedirectory"=>["/home/shermann"], "mail"=>["shermann.de"], "givenname"=>["Stephan"], "nsaccountlock"=>false}], "summary"=>"3 users matched"}


Additional info:

Comment 2 Martin Kosek 2013-06-21 10:24:28 UTC
I found out that this issue only reproduces when the client is not using the FreeIPA sessions and is doing the full delegation:

# ipa -vv user-show admin
ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/xml
...
reply: 'HTTP/1.1 200 Success\r\n'
...
header: Content-Type: text/plain; charset=UTF-8
...
header: WWW-Authenticate: Negotiate YIGYBgkqhkiG9x...JDIK9jtCPOA4JKDI=
...
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 1059000000
  GID: 1059000000
  Account disabled: False
  Password: True
  Member of groups: admins, trust admins
  Kerberos keys available: True

With second try the session is now used and correct Content-Type shows:

# ipa -vv user-show admin
ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/session/xml
...
reply: 'HTTP/1.1 200 Success\r\n'
...
header: Set-Cookie: ipa_session=503afc96694e344c68d27fe680cd001c; Domain=vm-133.idm.lab.bos.redhat.com; Path=/ipa; Expires=Fri, 21 Jun 2013 10:37:56 GMT; Secure; HttpOnly

...
header: Content-Type: text/xml; charset=utf-8
...
  User login: admin
  Last name: Administrator
  Home directory: /home/admin
  Login shell: /bin/bash
  UID: 1059000000
  GID: 1059000000
  Account disabled: False
  Password: True
  Member of groups: admins, trust admins
  Kerberos keys available: True


Your case can be easily reproducible the following way:
# ipa --delegate -vv user-show admin
ipa: INFO: trying https://vm-133.idm.lab.bos.redhat.com/ipa/xml
...
reply: 'HTTP/1.1 200 Success\r\n'
...
header: WWW-Authenticate: Negotiate
...
header: Content-Type: text/plain; charset=UTF-8

To sum it up, it is indeed a bug and I will clone it to upstream ticket.

Comment 3 Martin Kosek 2013-06-21 10:29:32 UTC
Upstream ticket:
https://fedorahosted.org/freeipa/ticket/3745

Comment 6 Kaleem 2013-10-03 14:19:27 UTC
Verified.

IPA version:
============
[root@rhel65-master ~]# rpm -q ipa-server
ipa-server-3.0.0-37.el6.x86_64
[root@rhel65-master ~]#


[root@rhel65-master ~]# ipa --delegate -vv user-show admin
ipa: INFO: trying https://rhel65-master.testrelm.com/ipa/xml
ipa: INFO: Forwarding 'user_show' to server u'https://rhel65-master.testrelm.com/ipa/xml'
send: u'POST /ipa/xml HTTP/1.0\r\nHost: rhel65-master.testrelm.com\r\nAccept-Language: en-us\r\nReferer: https://rhel65-master.testrelm.com/ipa/xml\r\nAuthorization: negotiate YIIFDgYJKoZIhvcSAQICAQBuggT9MIIE
....
reply: 'HTTP/1.1 200 Success\r\n'
....
header: Content-Type: text/xml; charset=utf-8
[root@rhel65-master ~]#

Comment 8 errata-xmlrpc 2013-11-21 20:53:59 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

http://rhn.redhat.com/errata/RHBA-2013-1651.html