Hi again,

We've successfully reached 27K policies (and counting). So far the
performance seems quite reasonable. There are two important details
I've forgot to mention in my previous mails:

1) ssoadm is disabled by default in the latest versions of OpenAM for
security reasons; it could (and in our case should) be enabled by
creating and configuring the following property:

ssoadm.disabled         false

accessible through the GUI at Configuration --> Servers and Sites -->
<your server> --> Advanced

2) c66Encode is turned on by default in the latest versions of OpenAM;
this gives cookies using '.' and '*' as separators instead of '#', '@'
and '=', as explained here:

https://wikis.forgerock.org/confluence/display/openam/Use+OpenAM+RESTful+Services

Here are one old and one new tokens side-by-side to illustrate the difference:

AQIC5wM2LY4RfckcedfzxGrgVYevbKR-SgBkuemF4Cmm5Qg=@AAJTSQABMDE=#
AQIC5wM2LY4RfckcedfzxGrgVYevbKR-SgBkuemF4Cmm5Qg.*AAJTSQABMDE.*

One important consequence of this is that the tokens don't need to be
percent encoded anymore :-)

On 4 July 2011 12:52, Andreas Maunz <andreas at maunz.de> wrote:

> Given your below results, the most important
> step besides upgrading will be a real powerful LDAP service for
> configuration store.

Yes, this is simply a must. In fact I'm convinced that as long as we
stick to the current rather resource demanding AA solution that we've
designed and implemented, we should probably run it on bare hardware,
not "in the cloud", in order to ensure satisfying performance. Another
important aspect would be fault tolerance (both OpenAM and OpenDJ
support load-balancing, failover and federating but this needs to be
investigated/tested further). In addition, for such a critical
component such as AA it is often required to have multiple servers,
running at different physical locations, to ensure proper level of
availability.

Kind regards,
Vedrin