I have a requirement to use an external (Microsoft Dynamics) data store to power the membership side of an Umbraco multi-site implementation. It will contain centralised login data and core profile info for each member, and also site-specific profile information. I am considering:
- Extending the Umbraco Membership Provider. I like this idea as the system is more akin to the Umbraco membership system than ASP.Net, as it will use different Member Types (for the different sites) as well as groups. However, as core profile data will not be stored in the Umbraco CMS DB, not sure if this is a viable option. The Umbraco Membership Provider is essentially just a wrapper for the Umbraco member API.
- Create a custom ASP.Net membership provider. This seems more flexible as data can be stored wherever but I imagine would involve a lot of work, and also would it mean I would need to implement a custom member dashboard to manage the external member data? I have tried to imlpement a SQL Memebership provider and although it will display the members, it is very limited in functionality and there does not seem to be a way to work with member types and profile data.
I guess I am looking for advice on how to tap into an external data store for member/profile info, but retain as much as possible in terms of the standard member dashboard. Maybe I am overlooking a simpler solution?
If you have your login and profile data into Microsoft Dynamics I would create a custom Membership provider. You can take a look at the Umbraco implementation for inspiration. If you want to select roles and profile data as well you need to implement a role and profile provider as well.It is time consuming but you can also decide to only implement the methods that you need.
I would also try to convince your client to maintain member/profile data in Microsoft Dynamics. This is because you can only modify member data with the default Umbraco provider, if you use a different provider data is read-only. This also counts for Role data. Only thing that does work is protecting content using a custom provider. So if you really need to update the data as well make sure you have enough budget to refactor the existing functionality to make it work on custom providers.
Thanks for the advice Richard. Essentially the client wants to store authentication information and common profile data in Microsoft Dynamics. However they want Umbraco to deal with access control and also store site-specific profile data (custom tables). To me this does not sound feasible, either use Umbraco membership, or implement a custom provider that handles everything.
I suppose I could consider building a custom membership system altogether that used Dynamics APIs to authenticate and custom methods to handle access control and site-specific profile. I know this would require a custom member section etc - I would not be able to use Umbraco membership at all. What do you think about this? What about implementing a more complex profile provider that could mimic the Umbraco member syste - i.e. different member types and groups?
I would go for the custom section, because I 100% agree you don't want to mix up the authentication, roles and profiles between two sections. Maybe Dynamics already comes with a Provider model so you "only" need to create the custom section?
Hey Richard, I can instruct the Dynamics dev to build an API according to my requirements so that's fine. Just need to decide whether to make it an ASP.Net membership provider or custom membership API. I think the ASP.Net membership provider will be too restrictive, as they want to have different sets of profile data depending on the service (so like member types). Is this somehting that could be achieved with a custom profile provider? The alternative would mean completely replacing the member system though and would be a bit daunting - none of the in-built member functionality will work, like protecting content nodes.
The IT boss prefers for the Dynamics database NOT to handle roles and profiles as he sees this as website-specific, and the Dynamics DB is for CRM. He essentially wants a relationship between the CRM 'master' record, which should hold the core member information (name, email etc) as well as the authentication details. The actual permissions should still be handled/stored by the website. I don't like the idea of separating these 2 elements either - my other option is to suggest simply overriding the ValidateUser method to process the login details (and perhaps the methods that save common member properties) and leave the rest of the system intact and stored within Umbraco. THe member DB might grow quite large though (250k members +) and again the IT boss is against storing it in the native Umbraco structure for performance reasons - his preference is for custom profile tables.
So I guess the main issue is the requirement for login info and common profile info to be stored in one place, and the (linked) info to control access and extended profile in another. THe secondary issue is the performance aspect, considering the potential size of the member DB. You have already been a great help in my thought process - but any further advice or opinion on how you would approach this would be much appreciated!
I think writing a custom Membership API will require you to write your own login controls etc, since it's not based on a Membership Provider. What you ofcourse can do is to only implement the Authentication and Role Provider. Then use a custom API to work with the Role data.I think you can only have one Role Provider configured anyway, so that will not work for you. Then refer to you custom role API instead of the asp.net Role provider.
Just take the Umbraco Mebership provider as an example. If you implement a cutom Mmebership and Role provider you can still use the public access functionality to assign roles to documents. Only thing that doesn't work is update role information in the Member section, you will see it's read only. If you want to modify Role data you should build this yourself. Same for the Member Data update functionality, If you don't make it Dynamic like Umbraco does with Membertypes that can be a simple CRUD form.
I think it's a good choice not to have 250K+ members in you Umbraco install :).
OK thanks Richard - I think I get you - are you saying implement a custom ASP.Net based membership and role provider, and then implement a custom API to deal with Profile info? I think Roles will be fine to use as standard - but as we need different profile properties for each site, I'll need to build a custom API to retrieve this data. I think that makes sense! Have you seen any good resources for creating a custom membership provider, especially regarding implementing with Umbraco? Is it best to derive my custom classes from System.Web.Security.MembershipProvider or UmbracoMembershipProvider? (In the case of a custom Membership provider)
Yes that's what I mean. You are right about the Role provider. one thing less to implement. I've recently implemented a Membership provider for Active Directory. and used the Umbraco providers as a starting point since that implemented all the features I needed and was easy to understand.
The dynamics CRM team implemented a custom, ASP.Net based membership and role provider which allowed me to use the standard ASP.net login controls for authentication and access control.
Check the return URL property, you can set that to redirect the member to the page of your choice on login. If they are actualy being bounced to the login page, it might be another problem like their account is not approved (and you require this), their account is locked or they are not a member of the required role. Step through the validateUser method and that should give you more info.
If you have implemented a custom membership role provider and referenced this in your web.config you will not be storing your members in Umbraco, the data will be pulled in via the provider API calls.
Plug in an external member DB: options
I have a requirement to use an external (Microsoft Dynamics) data store to power the membership side of an Umbraco multi-site implementation. It will contain centralised login data and core profile info for each member, and also site-specific profile information. I am considering:
- Extending the Umbraco Membership Provider. I like this idea as the system is more akin to the Umbraco membership system than ASP.Net, as it will use different Member Types (for the different sites) as well as groups. However, as core profile data will not be stored in the Umbraco CMS DB, not sure if this is a viable option. The Umbraco Membership Provider is essentially just a wrapper for the Umbraco member API.
- Create a custom ASP.Net membership provider. This seems more flexible as data can be stored wherever but I imagine would involve a lot of work, and also would it mean I would need to implement a custom member dashboard to manage the external member data? I have tried to imlpement a SQL Memebership provider and although it will display the members, it is very limited in functionality and there does not seem to be a way to work with member types and profile data.
I guess I am looking for advice on how to tap into an external data store for member/profile info, but retain as much as possible in terms of the standard member dashboard. Maybe I am overlooking a simpler solution?
Hi Barry,
If you have your login and profile data into Microsoft Dynamics I would create a custom Membership provider. You can take a look at the Umbraco implementation for inspiration. If you want to select roles and profile data as well you need to implement a role and profile provider as well.It is time consuming but you can also decide to only implement the methods that you need.
I would also try to convince your client to maintain member/profile data in Microsoft Dynamics. This is because you can only modify member data with the default Umbraco provider, if you use a different provider data is read-only. This also counts for Role data. Only thing that does work is protecting content using a custom provider. So if you really need to update the data as well make sure you have enough budget to refactor the existing functionality to make it work on custom providers.
Hope this helps you a bit.
Cheers,
Richard
Thanks for the advice Richard. Essentially the client wants to store authentication information and common profile data in Microsoft Dynamics. However they want Umbraco to deal with access control and also store site-specific profile data (custom tables). To me this does not sound feasible, either use Umbraco membership, or implement a custom provider that handles everything.
I suppose I could consider building a custom membership system altogether that used Dynamics APIs to authenticate and custom methods to handle access control and site-specific profile. I know this would require a custom member section etc - I would not be able to use Umbraco membership at all. What do you think about this? What about implementing a more complex profile provider that could mimic the Umbraco member syste - i.e. different member types and groups?
Hi Barry,
I would go for the custom section, because I 100% agree you don't want to mix up the authentication, roles and profiles between two sections. Maybe Dynamics already comes with a Provider model so you "only" need to create the custom section?
Cheers,
Richard
Hey Richard, I can instruct the Dynamics dev to build an API according to my requirements so that's fine. Just need to decide whether to make it an ASP.Net membership provider or custom membership API. I think the ASP.Net membership provider will be too restrictive, as they want to have different sets of profile data depending on the service (so like member types). Is this somehting that could be achieved with a custom profile provider? The alternative would mean completely replacing the member system though and would be a bit daunting - none of the in-built member functionality will work, like protecting content nodes.
The IT boss prefers for the Dynamics database NOT to handle roles and profiles as he sees this as website-specific, and the Dynamics DB is for CRM. He essentially wants a relationship between the CRM 'master' record, which should hold the core member information (name, email etc) as well as the authentication details. The actual permissions should still be handled/stored by the website. I don't like the idea of separating these 2 elements either - my other option is to suggest simply overriding the ValidateUser method to process the login details (and perhaps the methods that save common member properties) and leave the rest of the system intact and stored within Umbraco. THe member DB might grow quite large though (250k members +) and again the IT boss is against storing it in the native Umbraco structure for performance reasons - his preference is for custom profile tables.
So I guess the main issue is the requirement for login info and common profile info to be stored in one place, and the (linked) info to control access and extended profile in another. THe secondary issue is the performance aspect, considering the potential size of the member DB. You have already been a great help in my thought process - but any further advice or opinion on how you would approach this would be much appreciated!
Hi Barry,
I think writing a custom Membership API will require you to write your own login controls etc, since it's not based on a Membership Provider. What you ofcourse can do is to only implement the Authentication and Role Provider. Then use a custom API to work with the Role data.I think you can only have one Role Provider configured anyway, so that will not work for you. Then refer to you custom role API instead of the asp.net Role provider.
Just take the Umbraco Mebership provider as an example. If you implement a cutom Mmebership and Role provider you can still use the public access functionality to assign roles to documents. Only thing that doesn't work is update role information in the Member section, you will see it's read only. If you want to modify Role data you should build this yourself. Same for the Member Data update functionality, If you don't make it Dynamic like Umbraco does with Membertypes that can be a simple CRUD form.
I think it's a good choice not to have 250K+ members in you Umbraco install :).
Cheers,
Richard
OK thanks Richard - I think I get you - are you saying implement a custom ASP.Net based membership and role provider, and then implement a custom API to deal with Profile info? I think Roles will be fine to use as standard - but as we need different profile properties for each site, I'll need to build a custom API to retrieve this data. I think that makes sense! Have you seen any good resources for creating a custom membership provider, especially regarding implementing with Umbraco? Is it best to derive my custom classes from System.Web.Security.MembershipProvider or UmbracoMembershipProvider? (In the case of a custom Membership provider)
Hi Barry,
Yes that's what I mean. You are right about the Role provider. one thing less to implement. I've recently implemented a Membership provider for Active Directory. and used the Umbraco providers as a starting point since that implemented all the features I needed and was easy to understand.
Cheers,
Richard
Hi Barry,
I am also trying to integrate Umbraco with Dynamic CRM
I will be glad to hear what worked for you and what is the solution you choose finaly.
Thanks in advance
Erez
Hi Erez,
The dynamics CRM team implemented a custom, ASP.Net based membership and role provider which allowed me to use the standard ASP.net login controls for authentication and access control.
Hi Barry,
Thank you so much for your quick replay.
can you specify a bit more?
I also implimented costum role provider, so I can see all roles from my external system in the umbraco admin
also I have implimented costum membership provider (with only the ValidateUser() function )
but still when user login to a secure page, though he is validated - he is always being redirected to the login page.
I am also trying to migrate Umbraco with Dynamic CRM , and want to pull the members and roles from the CRM -
without the need to store them twice (in Umbraco also) , and stil keep the ability of Umbraco - "Role based protection"
I will really appreciate your help.
Thanks in advance
Erez
Check the return URL property, you can set that to redirect the member to the page of your choice on login. If they are actualy being bounced to the login page, it might be another problem like their account is not approved (and you require this), their account is locked or they are not a member of the required role. Step through the validateUser method and that should give you more info.
If you have implemented a custom membership role provider and referenced this in your web.config you will not be storing your members in Umbraco, the data will be pulled in via the provider API calls.
Good luck!
is working on a reply...