Subject: [scim] A short review of the password mgmt draft - Password Policy and the passwordState attribute

From: Erik Wahlström neXus <[email-masked]>
Date: Tue, 5 May 2015 16:52:03 +0000

Read through the draft-hunt-scim-password-mgmt draft to see how it matches our APIs for it credential management. Found some open issues that we can use for discussion points.

But first of all, thanks for working on this!

Split this up into two emails, one regarding “passwordState” and Password polices (this), and another one about Management requests.

I think the most important point it the following. I think we must create a level of abstraction on top of the password policy this, maybe called “Credential Policy” and maybe a credentialState extension attribute for User/Group that can have 1 to many different values  based on different policies bound to it. Sometimes it’s a normal password extension attributes for User/Group defined in the spec and sometime it’s an OATH token PIN policy and maybe information of a two factor authentication soften is fully provisioned or if only an activation message is sent to the user, but it’s not yet used and so on.

In our two factor authentication software (radius, saml, oauth2, plugin interface and a bunch of different methods-thingie) different types of credentials (authentication methods) can be assigned to a User. That means that a user can have both the neXus Password method, that’s a normal username/password based method. User can also have neXus Mobile Text that’s a a 2FA method that sends an OTP through SMS and an OATH based 2FA based token with a PIN assigned to the same User.

Different policies are configured for all the different authentication methods (matches the Password Policy defined in the draft). The username/password based methods largely matches the password policy in the spec, but how to define a PIN and configure if a username/password+otp should be entered in one or two steps can’t be added with the help of this draft. You also would like to define password policies on individual authentication methods, users and groups depending on the setup.

Did a quick mapping of the attributes against our APIs.
—————

In our IAM system called neXus Hybrid Access Gateway, the number of retries is not based on one of the authentication methods, but it’s a combination of all the different authentication methods (up on Credential Policy level?).

—————

Also missing “Use password from directory services”. If an account is bound to a directory service (AD, LDAP, DB…) it can use that password instead of a built in one in the system. It’s up to the administrator to select what password should be enabled (per authentication method) for a user. A password reset method also resets the AD password if it’s checked instead of a local password in the IAM system.

————

Example of missing attributes on the password schema for use by different types of 2FA authentication methods. For example sometimes you would like to activate a 2FA token and send out a provisioning link to the end user that’s used to establish seeds used for OATH calculations. That’s set on a password policy saying “Select to (re)activate softtoken by seed” or “Select to (re)activate soft token by activation code”.

Some web (html+js) based 2FA based authentication methods can also be provisioned using 2FA automatically for specific users (that’s usually non technical people with the power to override security policies) called “automatically activate on first logon”. Don’t see how that could be implemented either.

If it’s an authentication method that sends OTP:s in some form (paper, sms, email…) then the length of the OTP should also be possible to configure on the method. "OTP length”. It’s also bundled with "Generate Activation Code from” that contains a list of chars that’s used to generate the OTP (preferable a long list). But also an individual "Notification Message”. Sometimes the message should also be sent to another person (a boss that helps a user out of authentication to the system, then another notification message for other persons should also be defined (with replacements {0} and {1} for usernames and OTPs.

A virtual key board (in JS or applet) can also be configured in the policy to have either random keyboards or in numerical order.

OATH based methods (TOTP/HOTP/OCRA) have offsets and accept windows. 

———————

“resetAttempts”, should be a global value for the Credential Policy all authentication methods, and not bound to one specific password.

———————

“challenges” is not used all, concept is to fragile. I would recommend mentioning this in the security considerations sections.

—————

Did not really get the “passwordHistory” attribute, at least not the policy.passwordHistorySize thingie.

——————

“minSpecialChars” is not used in the system, but on the other hand "Disallowed characters" is. Sometimes the chars ‘1' and ‘l' is too close to each other and then a list of disallowed chars can be added. Especially when a password is initially generated in the system and sent to a user through some second channel (sms and so forth).

———————

/ Erik