yahoo-eng-team team mailing list archive
-
yahoo-eng-team team
-
Mailing list archive
-
Message #76719
[Bug 1813183] [NEW] x509 authentication doesn't work with auto-provisioning
Public bug reported:
Keystone supports the ability to authenticate users who have an x509
certificate [0]. Attributes from the certificate are parsed using an SSL
library and are passed to keystone (mod_ssl in the apache case).
Keystone uses the certificate attributes like attributes from a SAML
assertion and runs it through a mapping.
Keystone also supports auto-provisioning through mappings [1]. This is a
mapping with a special syntax that let's keystone know it should create
the underlying projects and role assignments for that user, in addition
to the shadow user.
It appears that none of the auto-provisioning works when authenticating
with x509 certificates. The following are the steps I took to determine
this.
1. ) Deploy devstack with the tls-proxy service enabled
disable_all_services
enable_service key
enable_service tls-proxy
enable_service horizon
enable_service mysql
enable_service tempest
enable_service rabbit
2.) Remove http-services-tls-proxy.conf Apache configuration
$ sudo rm /etc/apache2/sites-available/http-services-tls-proxy.conf
For some reason, this doesn't work with keystone and SSL.
3.) Configure SSL for keystone in Apache configuration
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile /opt/stack/data/devstack-cert.pem
SSLCACertificateFile /opt/stack/data/CA/root-ca/cacert.pem
SSLOptions +StdEnvVars
SSLVerifyClient optional
SSLUserName SSL_CLIENT_S_DN_CN
SetEnv REMOTE_DOMAIN openstack
</Virtualhost>
4.) Configure x509 authentication in keystone.conf
[tokenless_auth]
# trusted issuer comes from the Issuer of the SSLCACertificateFile
# from the Apache configuration, where $CERT_PATH is SSLCACertificateFile.
# Use openssl to figure out the Issuer and reformat the ordering of the string
# to be as follows.
trusted_issuer = CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack
[auth]
methods = password,token,external
external = Domain
5.) Create a certificate request, private key, and certificate for a
user
$ openssl req -out john.csr -new -newkey rsa:2048 -nodes -keyout
john.key
When prompted for the organization (O) enter the domain for the user.
A domain with the same name as the organizational unit will need to be
created in keystone. The common name of the certificate request will be
the user's username within keystone, depending on the specific mapping.
$ openssl x509 -req -in john.csr -CA $ROOT_CA -CAkey $ROOT_KEY -days 365
-out john.pem -CAcreateserial
6.) Create the identity provider and mapping in keystone
The identity provider ID is the hashed trusted_issuer string from the
configuration file:
./hash 'CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack'
ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
https://gist.github.com/lbragstad/5338e8bfdcc1158ceaedffd4036e671e
$ openstack identity provider create ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
$ openstack mapping create x509map --rules rules.json
$ openstack federation protocol create x509 --mapping x509map --identity-provider ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
The following is the rules.json I used:
https://pasted.tech/pastes/a825b80d51c6e01d87d0b692a1c1d30c275b72b4.raw
7.) Authenticate for a token
When I authenticate for a token using the certificate I created, I get
an unscoped token. Also, none of the auto-provisioned resources are
created through the mapping. The expected behavior is that the auto-
provisioning feature would handle the creation of those resources and
I'd be able to get a scoped token.
https://pasted.tech/pastes/e51f35565c923c2469dc44ec5f42cca8ecc1cf9f.raw
[0]
https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html#create-a-map
** Affects: keystone
Importance: Undecided
Status: New
** Description changed:
Keystone supports the ability to authenticate users who have an x509
certificate [0]. Attributes from the certificate are parsed using an SSL
library and are passed to keystone (mod_ssl in the apache case).
Keystone uses the certificate attributes like attributes from a SAML
assertion and runs it through a mapping.
Keystone also supports auto-provisioning through mappings [1]. This is a
mapping with a special syntax that let's keystone know it should create
the underlying projects and role assignments for that user, in addition
to the shadow user.
It appears that none of the auto-provisioning works when authenticating
with x509 certificates. The following are the steps I took to determine
this.
1. ) Deploy devstack with the tls-proxy service enabled
disable_all_services
- enable_service key
+ enable_service key
enable_service tls-proxy
enable_service horizon
enable_service mysql
enable_service tempest
enable_service rabbit
2.) Remove http-services-tls-proxy.conf Apache configuration
$ sudo rm /etc/apache2/sites-available/http-services-tls-proxy.conf
For some reason, this doesn't work with keystone and SSL.
3.) Configure SSL for keystone in Apache configuration
<VirtualHost *:443>
- SSLEngine On
- SSLCertificateFile /opt/stack/data/devstack-cert.pem
- SSLCACertificateFile /opt/stack/data/CA/root-ca/cacert.pem
- SSLOptions +StdEnvVars
- SSLVerifyClient optional
- SSLUserName SSL_CLIENT_S_DN_CN
- SetEnv REMOTE_DOMAIN openstack
+ SSLEngine On
+ SSLCertificateFile /opt/stack/data/devstack-cert.pem
+ SSLCACertificateFile /opt/stack/data/CA/root-ca/cacert.pem
+ SSLOptions +StdEnvVars
+ SSLVerifyClient optional
+ SSLUserName SSL_CLIENT_S_DN_CN
+ SetEnv REMOTE_DOMAIN openstack
</Virtualhost>
4.) Configure tokenless authentication in keystone.conf
[tokenless_auth]
# trusted issuer comes from the Issuer of the SSLCACertificateFile
# from the Apache configuration, where $CERT_PATH is SSLCACertificateFile.
# Use openssl to figure out the Issuer and reformat the ordering of the string
# to be as follows.
trusted_issuer = CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack
[auth]
methods = password,token,external
external = Domain
5.) Create a certificate request, private key, and certificate for a
user
$ openssl req -out john.csr -new -newkey rsa:2048 -nodes -keyout
john.key
When prompted for the organization (O) enter the domain for the user.
A domain with the same name as the organizational unit will need to be
created in keystone. The common name of the certificate request will be
the user's username within keystone, depending on the specific mapping.
$ openssl x509 -req -in john.csr -CA $ROOT_CA -CAkey $ROOT_KEY -days 365
-out john.pem -CAcreateserial
6.) Create the identity provider and mapping in keystone
The identity provider ID is the hashed trusted_issuer string from the
configuration file:
./hash 'CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack'
ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
https://gist.github.com/lbragstad/5338e8bfdcc1158ceaedffd4036e671e
$ openstack identity provider create ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
$ openstack mapping create x509map --rules rules.json
$ openstack federation protocol create x509 --mapping x509map --identity-provider ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
The following is the rules.json I used:
https://pasted.tech/pastes/a825b80d51c6e01d87d0b692a1c1d30c275b72b4.raw
7.) Authenticate for a token
When I authenticate for a token using the certificate I created, I get
an unscoped token. Also, none of the auto-provisioned resources are
- created through the mapping.
+ created through the mapping. The expected behavior is that the auto-
+ provisioning feature would handle the creation of those resources and
+ I'd be able to get a scoped token.
https://pasted.tech/pastes/e51f35565c923c2469dc44ec5f42cca8ecc1cf9f.raw
[0]
https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html#create-a-map
** Summary changed:
- Tokenless authentication doesn't work with auto-provisioning
+ x509 authentication doesn't work with auto-provisioning
** Description changed:
Keystone supports the ability to authenticate users who have an x509
certificate [0]. Attributes from the certificate are parsed using an SSL
library and are passed to keystone (mod_ssl in the apache case).
Keystone uses the certificate attributes like attributes from a SAML
assertion and runs it through a mapping.
Keystone also supports auto-provisioning through mappings [1]. This is a
mapping with a special syntax that let's keystone know it should create
the underlying projects and role assignments for that user, in addition
to the shadow user.
It appears that none of the auto-provisioning works when authenticating
with x509 certificates. The following are the steps I took to determine
this.
1. ) Deploy devstack with the tls-proxy service enabled
disable_all_services
enable_service key
enable_service tls-proxy
enable_service horizon
enable_service mysql
enable_service tempest
enable_service rabbit
2.) Remove http-services-tls-proxy.conf Apache configuration
$ sudo rm /etc/apache2/sites-available/http-services-tls-proxy.conf
For some reason, this doesn't work with keystone and SSL.
3.) Configure SSL for keystone in Apache configuration
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile /opt/stack/data/devstack-cert.pem
SSLCACertificateFile /opt/stack/data/CA/root-ca/cacert.pem
SSLOptions +StdEnvVars
SSLVerifyClient optional
SSLUserName SSL_CLIENT_S_DN_CN
SetEnv REMOTE_DOMAIN openstack
</Virtualhost>
- 4.) Configure tokenless authentication in keystone.conf
+ 4.) Configure x509 authentication in keystone.conf
[tokenless_auth]
# trusted issuer comes from the Issuer of the SSLCACertificateFile
# from the Apache configuration, where $CERT_PATH is SSLCACertificateFile.
# Use openssl to figure out the Issuer and reformat the ordering of the string
# to be as follows.
trusted_issuer = CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack
[auth]
methods = password,token,external
external = Domain
5.) Create a certificate request, private key, and certificate for a
user
$ openssl req -out john.csr -new -newkey rsa:2048 -nodes -keyout
john.key
When prompted for the organization (O) enter the domain for the user.
A domain with the same name as the organizational unit will need to be
created in keystone. The common name of the certificate request will be
the user's username within keystone, depending on the specific mapping.
$ openssl x509 -req -in john.csr -CA $ROOT_CA -CAkey $ROOT_KEY -days 365
-out john.pem -CAcreateserial
6.) Create the identity provider and mapping in keystone
The identity provider ID is the hashed trusted_issuer string from the
configuration file:
./hash 'CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack'
ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
https://gist.github.com/lbragstad/5338e8bfdcc1158ceaedffd4036e671e
$ openstack identity provider create ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
$ openstack mapping create x509map --rules rules.json
$ openstack federation protocol create x509 --mapping x509map --identity-provider ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
The following is the rules.json I used:
https://pasted.tech/pastes/a825b80d51c6e01d87d0b692a1c1d30c275b72b4.raw
7.) Authenticate for a token
When I authenticate for a token using the certificate I created, I get
an unscoped token. Also, none of the auto-provisioned resources are
created through the mapping. The expected behavior is that the auto-
provisioning feature would handle the creation of those resources and
I'd be able to get a scoped token.
https://pasted.tech/pastes/e51f35565c923c2469dc44ec5f42cca8ecc1cf9f.raw
[0]
https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html#create-a-map
--
You received this bug notification because you are a member of Yahoo!
Engineering Team, which is subscribed to OpenStack Identity (keystone).
https://bugs.launchpad.net/bugs/1813183
Title:
x509 authentication doesn't work with auto-provisioning
Status in OpenStack Identity (keystone):
New
Bug description:
Keystone supports the ability to authenticate users who have an x509
certificate [0]. Attributes from the certificate are parsed using an
SSL library and are passed to keystone (mod_ssl in the apache case).
Keystone uses the certificate attributes like attributes from a SAML
assertion and runs it through a mapping.
Keystone also supports auto-provisioning through mappings [1]. This is
a mapping with a special syntax that let's keystone know it should
create the underlying projects and role assignments for that user, in
addition to the shadow user.
It appears that none of the auto-provisioning works when
authenticating with x509 certificates. The following are the steps I
took to determine this.
1. ) Deploy devstack with the tls-proxy service enabled
disable_all_services
enable_service key
enable_service tls-proxy
enable_service horizon
enable_service mysql
enable_service tempest
enable_service rabbit
2.) Remove http-services-tls-proxy.conf Apache configuration
$ sudo rm /etc/apache2/sites-available/http-services-tls-proxy.conf
For some reason, this doesn't work with keystone and SSL.
3.) Configure SSL for keystone in Apache configuration
<VirtualHost *:443>
SSLEngine On
SSLCertificateFile /opt/stack/data/devstack-cert.pem
SSLCACertificateFile /opt/stack/data/CA/root-ca/cacert.pem
SSLOptions +StdEnvVars
SSLVerifyClient optional
SSLUserName SSL_CLIENT_S_DN_CN
SetEnv REMOTE_DOMAIN openstack
</Virtualhost>
4.) Configure x509 authentication in keystone.conf
[tokenless_auth]
# trusted issuer comes from the Issuer of the SSLCACertificateFile
# from the Apache configuration, where $CERT_PATH is SSLCACertificateFile.
# Use openssl to figure out the Issuer and reformat the ordering of the string
# to be as follows.
trusted_issuer = CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack
[auth]
methods = password,token,external
external = Domain
5.) Create a certificate request, private key, and certificate for a
user
$ openssl req -out john.csr -new -newkey rsa:2048 -nodes -keyout
john.key
When prompted for the organization (O) enter the domain for the user.
A domain with the same name as the organizational unit will need to be
created in keystone. The common name of the certificate request will be
the user's username within keystone, depending on the specific mapping.
$ openssl x509 -req -in john.csr -CA $ROOT_CA -CAkey $ROOT_KEY -days
365 -out john.pem -CAcreateserial
6.) Create the identity provider and mapping in keystone
The identity provider ID is the hashed trusted_issuer string from the
configuration file:
./hash 'CN=Root CA,OU=DevStack Certificate Authority,O=OpenStack'
ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
https://gist.github.com/lbragstad/5338e8bfdcc1158ceaedffd4036e671e
$ openstack identity provider create ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
$ openstack mapping create x509map --rules rules.json
$ openstack federation protocol create x509 --mapping x509map --identity-provider ad9b5af1ba36ffc36e1fbf7af5e83e25aebf66bbfefc12eed0313a875e6f9663
The following is the rules.json I used:
https://pasted.tech/pastes/a825b80d51c6e01d87d0b692a1c1d30c275b72b4.raw
7.) Authenticate for a token
When I authenticate for a token using the certificate I created, I get
an unscoped token. Also, none of the auto-provisioned resources are
created through the mapping. The expected behavior is that the auto-
provisioning feature would handle the creation of those resources and
I'd be able to get a scoped token.
https://pasted.tech/pastes/e51f35565c923c2469dc44ec5f42cca8ecc1cf9f.raw
[0]
https://docs.openstack.org/keystone/latest/admin/configure_tokenless_x509.html#create-a-map
To manage notifications about this bug go to:
https://bugs.launchpad.net/keystone/+bug/1813183/+subscriptions
