Hi Nicola,
ACS 5.x works in a waterfall fashion. First the shell profiles and command sets, then you should the authentication protocols, then the user database, then how you map the users to their authorization rules. Let's say you want users to authenticate in two ways: Auth A and Auth B.
1) If you plan on using user groups, make sure to create identity user groups which will be mapped to your external databases. For example group Local_Admins will be matched to Domain_Admins by LDAP.
2) Create the shell profiles and command sets. Shell profiles is for mapping attributes to Radius and Tacacs replies, command sets are for TACACS+ and allow you to configure exactly which commands that user can perform. If you don't need TACACS+ you can skip the command set. An example of a shell profile is to allow change idle-time and set privilege level to 15.
3) Make access profiles, for example one which allows Auth A and one which allows Auth B. You'd match these by tacacs or radius. You can decide here if you want to authenticate by Identity (user database), Group mapping and apply authorization rules. You can select any of these three. If you use local users then you won't need to use group mapping. Each of these can consist of complex rules or a single rule.
4) Under Identity you will match the source of your user database to the access profile. For example, for access profile A users from database A will be authenticated by Auth A. Databases can include internal databases, LDAP, AD etc.
5) We now know where to find the users who will be authenticated by Auth A for radius/tacacs. Now we need to use group mapping so that we can connect the external database to our identity groups from an earlier step. This can be one-to-one mapping, or many-to-one mapping. This means I can map multiple external groups to a single Identity group.
6) Authorization. For the mapped identity group which will be authenticated by Auth A from user database A we will apply a shell profile and command set according to certain criteria. For example let's say that our NAS is a router at home, then we can customize the authorization so that if the network device group is that of Home_Routers then apply a certain shell profile, you can skip command set if you don't need it in any of your authorization rules for a specific access profile (for example RADIUS).
All in all I don't feel this was more complicated than ACS 4.x since ACS 4.x sometimes caused a mess of configurations when users in the same group needed to authenticate via different methods and with different attributes. ACS 5.x makes things more clear cut and readable.
Hope this helped.
