[security-dev] managing OTP

[Boleslaw Dawidowicz]

On Aug 12, 2013, at 3:38 PM, Pedro Igor Silva <psilva at redhat.com> wrote:

> ----- Original Message -----
>> From: "Anil Saldhana" <Anil.Saldhana at redhat.com>
>> To: security-dev at lists.jboss.org
>> Sent: Monday, August 12, 2013 10:23:07 AM
>> Subject: Re: [security-dev] managing OTP
>> 
>> On 08/12/2013 08:20 AM, Bill Burke wrote:
>>> 
>>> On 8/12/2013 6:19 AM, Pedro Igor Silva wrote:
>>>> ----- Original Message -----
>>>>> From: "Bill Burke" <bburke at redhat.com>
>>>>> To: security-dev at lists.jboss.org
>>>>> Sent: Sunday, August 11, 2013 8:58:27 AM
>>>>> Subject: [security-dev] managing OTP
>>>>> 
>>>>> There's a few issues with managing credentials.  The first is, there is
>>>>> no way to remove a credential.  This is essential to TOTP as you may end
>>>>> up with a lost or obsolete device.
>>>>> 
>>>>> https://issues.jboss.org/browse/PLINK-236
>>>>> 
>>>> I missed that too and have discussed that with Shane a long time ago. The
>>>> idea is to have a history of all account's credentials.
>>>> 
>>> The reason for this is?
>>> 
>>>> If a devices becomes obsolete, you just set expiration date.
>>>> 
>>> Its not just TOTP, same with password.  Every time a user has a lost
>>> password two new obsolete ones are added to the database:  temporary
>>> one, then a password change.  Maybe not such a big deal with a few
>>> users, but when you get to tens, hundreds of thousands of users, won't
>>> this kind of be a problem?
>> There will be thousands of users for PicketLink IDM. As Bolek can
>> attest, PL 1.x IDM had that usage.
>> Pedro, lets review this password/credential issue.
>> 
> 
> Let's do this.

Please don't think thousands. It will show nothing :) It is a good exercise to make to feed your storage with 1M users, 200k of groups and/or roles, define membership and etc. Set at least 20 attributes for each user. Perform some operations - like mentioned setting credentials. Make sure to perform various types of queries. This is the level at which your SSD, 8GB of RAM and quad core CPU can't fake you anymore. 

Relatively quick and simple to setup on your laptop but quite good to identify weak spots in storage implementation. This is also fairly true scenario. Enterprise class customer can easily have that number of external users. Bigger organisation will have crazy amount of groups in LDAP and you may need to sync all of them into DB. Also with so flexible schema developers will abuse it by mapping all possible permission types to big set of roles - even if you could do it more efficient in different way. Sadly you cannot ban wrong usage of your model ;)

As you are currently discussing JDBC storage I would suggest implementing such tests early. Outcome can easily lead you to complete redesign of your storage implementation. Also it matters to measure time of certain operations and see how they scale depending on numbers of users. This can also help to identify leaks like the one pointed by Bill. Also my personal assumption is that with so flexible implementation like you have with JPA you won't be able to maintain scalability easily. It is better to verify. It took me and Marek a lot of time and careful fine tuning to make it perform for JPP and it didn't happen without tradeoffs. 

This is the PL IDM 1.x experience to share :) 

> 
>>>>> THe 2nd is that for TOTP, you will want to check every device on a
>>>>> credential validation rather than just one:
>>>>> 
>>>>> https://issues.jboss.org/browse/PLINK-237
>>>>> 
>>>>> Our own VPN allows me to set up multiple tokens.  I have one on my
>>>>> iphone and ipad just in case I lose one or the other.  OUr VPN allows me
>>>>> to use either to login in.
>>>>> 
>>>> Is not a valid option you iterate over user's devices and try each one ?
>>>> 
>>> Sure, this is why this is an enhancement.
>>> 
>> 
>> _______________________________________________
>> security-dev mailing list
>> security-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/security-dev
>> 
> _______________________________________________
> security-dev mailing list
> security-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/security-dev