pátek 2. října 2015

ovirt-engine-extension-aaa-jdbc introduction & settings customization

oVirt 3.6 introduced new extension called  ovirt-engine-extension-aaa-jdbc. If you upgrade from older version or if you install fresh new 3.6 you will have this extension installed and configured. With this extension you can store you users/group in database. Very good for people who don't need much users and don't want to deploy LDAP. Note that your admin@internal will now be part of this extension, this migration is done transparently by engine-setup.

Auth[zn] files for internal extension can be found in etc/ovirt-engine/extensions.d/internal-authz.properties and etc/ovirt-engine/extensions.d/internal-authn.properties. Nothing interesting can be found those two files. In common configuration of auth[zn] you can then find database connection settings, which you will find in etc/ovirt-engine/aaa/internal.properties. Content of the file looks like: As you can see only there are db connection details specified, so very easy configuration. Please note there is specified name of postgresql schema, which is in this case aaa_jdbc.

Exploring tables

Wanna check the data aaa-jdbc extension store? You can do as follows:
As you can see your admin account is now part of this extension as said above.
Well, this is not too comfortable to work with your users. The extension provide CLI tool to manage the users more comfortable way.

CLI tool 

Cli too name is ovirt-aaa-jdbc-tool. Not much I can say about this tool, since it has good documentation in help.
So whenever you are in doubt what to use just append --help to your args. Please note that by default use the command user @internal extension. If you want to use different one just pass --db-config=/path/to/db/settings.properties of your configuration.

Adding user via CLI tool

If you explored help of this tool you can see there is user module, which you can use to manage users. So we will add  some users, which we will use later in this blog post. Please note that by default freshly added users don't have set password, so you need to set it.

Changing settings via CLI tool

As there is user module there is also settings module to change settings of aaa-jdbc extension. To see what you can change simply run 'ovirt-aaa-jdbc-tool settings show'. There are lot of stuff you can change, the most important/interesting I will show you later.

Policies

Password history limit

You can use setting option PASSWORD_HISTORY_LIMIT  to prohibit user to set same password as he used before. Limit can be integer value, by default it's 3. That means user can't change password to last three passwords he used before.

To change it, use command below(set it to 5):

Password complexity 


Minimal lenght
To set minimal lenght of password you have to change MIN_LENGTH option. By default it's 6. Password complexity
To set complexity of password you have to change PASSWORD_COMPLEXITY option. You can create different complexity groups. By default there is no restriction.  So if you want to for example your user force to have at least one upper case letter, lower case letter and number in his password run the command below:

Account & login policy

 

Non locking policy after failed login
To prevent brute force attacks to your account and at the same time prevent denial of your account you can set non locking policy when there is too many attempts to guess password to your user account. To set it use MAX_FAILURES_PER_MINUTE option. By default it's set to 6.

Locking of account after failed login
You account can be locked after X failed logins. There are two options to configure that.
First possibility is to set  MAX_FAILURES_SINCE_SUCCESS this option means that user account is locked after X unsuccessfull login attempts to your account after last successfull login.

The second possibility is to set MAX_FAILURES_PER_INTERVAL this options means that your user account will be locked after X unsuccesfull login attempts to your account in X hours. The value of hours can be set  in option INTERVAL_HOURS.

Your accounts are locked to X minutes. The amount of minutes can be changed by value of option LOCK_MINUTES. Or you can unlock your user by running cli command:
$ ovirt-aaa-jdbc-tool user unlock user1

Removing of failed login
Failed login can be automatically removed during house keeping. All failed login which are older then X days specified in option FAILED_LOGINS_OLD_DAYS will be removed.

Other

 

Max login minutes

With MAX_LOGIN_MINUTES option you can set how long your user can be logged in. If time exceeds, he will be automatically logged out.

Many others

There are many other options. You can explore them by yourself, just run:
$ ovirt-aaa-jdbc-tool settings show

úterý 19. května 2015

SAML and oVirt 3.5

Same way as kerberos is supported for oVirt 3.5 there is also support for SAML via apache module.

There are few SAML apache modules, but I chose mod_auth_mellon, as it has very nice documentation.

First of all we need to setup some identity provider. I chose OpenAM. Please follow steps to quick install of OpenAM with embedded OpenDJ ldap.

OK I presume, that you have up and running OpenAM on tomcat with embedded OpenDJ ldap.
Next step is to setup ourt OpenAM as Identity Provider. Go to 'common-tasks' tab and hit the button 'Created Hosted Identity Provider'. Set name  of your metadata(your URL). Signing key, if you want. Then create new CoT and named it as you like, not important for us. Now very important thing. You need to add attribute mapping, so we are able to map the uid of user in ldap to REMOTE_USER env of apache. Please set 'Name in assertion' to 'common-name' and 'Local attribute name' to 'cn'. And we are done.

Apache configuration

Now we need to setup oVirt apache as service provider(I am using RHEL 6.6):
  • Install mod_auth_mellon apache module:
  • Obtain IdP metadata:
  • Create SP metadata:
  • Previous step will create for you three files:
             WHAT_EVER_SP_ENTITY_NAME_ID.xml
             WHAT_EVER_SP_ENTITY_NAME_ID.key
             WHAT_EVER_SP_ENTITY_NAME_ID.cert 
  • copy them to the /etc/httpd/mellon  and asure that all files and folder can be read by apache.
  • Create mod_auth_mellon configuration:
  • In OpenAM go to 'common-tasks' , hit 'register remote service provider'. Upload your SP metadata WHAT_EVER_SP_ENTITY_NAME_ID.xml. Choose already cretead CoT. That's all, click 'configure'.

oVirt AAA configuration

We had setup both mod_auth_mellon as SP and OpenAM as IdP. Last thing is to setup oVirt to respect this setup.
  • Install oVirt AAA packages:
  • Authn configuration:
  • Authz configuration:
  • Connection configuration:
  • This is custom properties file of opendj, I've created it for this example saml configuration. It's not supported by oVirt:
  • Check correct persmissions of all properties file, it have to be readeble by oVirt.

No we will create test user in OpenDJ. Go to OpenAM -> 'Access Control' tab -> select your realm (default /). Click 'Subjects' tab -> Add new user -> Fill appropriate values. (ie user1.)

Now go to oVirt webadmin and search within 'http' profile for user1 and assign him permissions. Now go to ovirt-engine/api URL and you will be forwarded to OpenAM login screen, fill your credentials and you are now able to access rest-api.