CODEWITHSUNDEEP
single-sign-onopenam
Kunal Aggarwal
Kunal Aggarwal

Reputation: 301

OpenAM Policy Evalution is slow with 100s of users

I have the latest enterprise build of OpenAM (12.0.0) deployed behind the latest Tomcat (7.0.62). I've also used the latest OpenDJ (2.6.0) for both User and Data Store. I followed the exact steps as mentioned in the Install Guide for OpenAM. Following are the JVM options set, according to production needs:

-Xmx2048m -XX:MaxPermSize=256m -XX:PermSize=256m -verbose:gc -server

Following is the setup for the realms:

/ (Root Realm) -> http://sso-admin.domain.com/openam The Data Store for this is the default SunDS Data Store to just use amadmin to login and do admin configuration. From here all sub-realms are accessible.

/Internal (Sub-Realm of the Root Realm) -> http://sso.domain.com/openam This is used by our organization to login. The Data Store for this is our Active Directory. All Agents and Policies are configured here.

Now the problem exists in the Internal Realm. I have an Apache Application running, for which I have to provide Authentication and Authorization (Policy based). I have created Policies using wildcards, and defined Subject conditions with around 250 users. Agent is installed and running perfectly. When the user opens the link to the app, http://myapp.domain.com, they get redirected to the http://sso.domain.com/openam page where they can use their AD credentials to login. But the policy evaluation takes around 2-3 minutes, after which the user is redirected to the app.

I even tested, to check, adding just 2 users to the Subject conditions rather than those 250 and it works instantly. I get redirected to the app instantaneously.

Why is this delay happening in policy evaluation? And how can I fix this? I thought OpenAM could handle 1000s of users, but in 250+ users it is taking so much time.

Any help is appreciated!

Upvotes: 0

Views: 418

Answers (1)

AndyF
AndyF

Reputation: 1094

Could you explain in more depth what your policies look like? Have you got individual policies, each with 250 users? Also, when you're testing evaluation are you making a single call to represent a single user session or multiple simultaneous calls?

Update: Yeah, I'd probably recommend against having 250 subject conditions; that sounds expensive to run. I'd consider using a group to represent those users. Assuming you've used OR to join all the subject conditions, the logic is optimised such that as soon as one is successful there's no need to evaluate the rest. However, if the valid subject is the last in the list that's a lot processing.

Right now the policy engine indexes on the resource but we're planning to build out on this, which will also include subject indexing. So if groups doesn't work for you, then you'd be better placed to model this as 250 policies each with a single subject condition (or much simpler rules anyhow). Therefore, when a request comes in for a particular resource being accessed by a specific user, the policy engine will local the policy of interest without having to evaluate all other polices.

Andy

Upvotes: 0

Related Questions