Investigate compatibility with Profile 2

This is what I was looking for. I have a profile2 user profile type on cas server (where the accounts are created) I need to duplicate the same profile type on cas client with profile2 attributes mapped from cas server to cas client. Is there currently any work around to do so.

I'm afraid there's no real "workaround", but if you're a developer and don't mind digging in with some custom code I can point you to where to start.

• The server side is easy - you just have to implement hook_cas_server_attributes to store the profile2 fields in attributes of your choosing. CAS Server implements its own hook, so you can just look at cas_server_cas_server_attributes() for an example (basically, you just return an array of values you want to send keyed with whatever attribute names you want to give them).
• The client side is not much harder to implement, but trickier to understand. CAS Attributes's hook_tokens() is where the attributes are actually fetched, but all you really have to do is implement hook_cas_user_presave() and follow the example of CAS Attributes.

Building proper, generic Profile2 support into CAS Attributes isn't really a big technical challenge; the biggest hassle would be figuring out the cleanest way to lay out the admin interface for it. (In your case you could cheat and just hard-code the attribute to profile field relationships you need, but if you are ambitious enough to cook up a good generic solution, patches are more than welcome.)

Thanks olarin for your detailed response. I will try to look at the cas module code to find out where and how I can add to it to be able to map my custom profile type fields to the cas user profile on client. It is actually profile2 to profile2 mapping. This solution has been a nightmare I have been spending days find a suitable way to map profile2 fields. I looked at feeds but was not sure how secure it is. I am at the moment battling with services/wsclient modules (using rules to set data). The REST service is set up correctly, it is only the client which is not connecting (wsclient does not provide even a way to enter user and password in UI for session authentication). The cas login session does not work services (between cas server and client). There are very few services client.

I have already implemented cas in my sites and it would be good if cas has the profile2 mapping feature. It will save people from hunting other places just for a solution to map profile2 fields. I don't think so that I am competent enough at coding to come up with a generic solution but I will definitely give a try to cheating. Is there a possibility that CAS developers can come up with a generic solution.

Something I almost forgot to mention - CAS attributes aren't a very secure way to pass user data unless the CAS Server is checking authentication clients against a whitelist, and only allowing your sites to authenticate (otherwise anyone else could set up their site to use your CAS Server to authenticate, and if they can trick people in to logging into their site using your CAS Server, they could collect those users' CAS attributes). The cas_server module does not yet have whitelisting support but there's a patch in the following issue which you can use: #1260588: CAS Server service whitelisting

I was looking at the possibilities with suggested method in #2. After looking at #4 and #5 I am now thinking if I should even try. In prepration of #2 I was still searching as to what to use to represent profiles object instead of $account (ex. $profiles or something else)??. Thanks

Valid point about "malicious" users still being able to read their own attributes bfroehle, although my concern was about malicious third-party sites using social engineering to trick gullible users into logging into their site via the CAS server and thus the third party collecting that gullible user's attributes, which whitelisting should prevent (unless the third party has hacked the user's personal computer in which case that user probably has much bigger problems anyway). But yes, attributes should never be used for data which is to be kept secure from even the user themself. If you have really really sensitive data in these profiles, a Services or RestWS solution is probably the safer route to go.

Anyway, to get back to the original point of this issue: I'm not likely to have the time or inclination to pursue profile2 support for this module myself in the near future, given that there doesn't appear to be a huge wave of interest in it. Of course if someone else wants to give it a try, then as always, patches are welcome.