AsyncOS 5.6.0 for Web is now Generally Available

Question

I am pleased to announce the "GA" release of 5.6.0. Code named "Maui" internally, this release is primarily focused on core proxy functionality. We have had great feedback from our beta testers and early adopters. I encourage customers to give 5.6.0 a try.
A few notes:
We have changed the way policies work and also added a new authentication layer called "identities". After upgrade we strongly recommend customers verify the post upgrade configuration to ensure policies and identities have been migrated appropriately to match your business needs.
If HTTPS was enabled and then is disabled at the time of upgrade, any archived decryption policies will not be maintained during the upgrade.
To enhance the security of the WSA, we explicitly prevent the WSA from proxying requests on the P2 interface. Customers who need this functionality may want to wait for the 5.6.2 release, which will support this configuration.
New Features in 5.6.0
* New Feature: Multi-core scanning (for improved performance)
* New Feature: Time-based policies for URL filtering
* New Feature: Enhanced routing policies (failover, load balancing, and conditional routing to multiple upstream proxies)
* New Feature: User-agent based policies
* New Feature: Policy trace tool
* New Feature: Custom EUN pages
* New Feature: SNMP enhancements (SNMPv1, 2, and 3, with support for traps and community strings)
* New Feature: Transparent bypass list
* New Feature: PAC file hosting
* New Feature: Active mode FTP over HTTP
* New Feature: GUI-based packet capture
Let us know what you think.
Regards,
Chris Haag
Manager, Technical Support

Answer 1

I need two identical identity policies that just say the authentication is CORP. Then in the access policies I limit the users. It would seem the user limiting should be done in the Identity Policy.
No, you only need one identity! In fact, if you've got 2 identities which are the same then the 2nd one will never actually match.
Identities and Access Policies are both a top-down, first match - with identities done first. So in your case you'd need one identity matching the domain CORP, and then in the access policy you can further limit that since identity based on the username.
Processing-wise it will do a top-down match on the identity to find the first match (your CORP identity) and then do a top-down match in the access policies to find a policy based on the CORP identity which matches the extra criteria you've added (ie, specific users/groups).
You can certainly end up in a situation where you can implement the same rules in a few different ways through a mixture of identities/policies, but at the end of the day it probably doesn't matter how you do it - pick whichever makes most sense for you!