I am designing a service application built on CSLA that leverages all of the security features available. As such, client applications that call the service interface must submit login credentials in order to use the service. For the most part, these client applications will be built by third parties; however, we are putting together an SDK and are experiencing some of the pains a client would. I'd like to address a few of these and make our service better and easier for clients to work with.
The issue at hand is determining how to best provide certain configuration information that describes how the service behaves to the client so they can modify their UI in response. I'll use authentication as the basis for the question.
When validating parameters for a service, the easiest approach is to simply pass them to the service and wait for the service return an error or whatever indicating that a problem exists. However, I'd like to support a more interactive (and responsive) UI. So, take the case where a user wants to use the ASP.NET Login control, for instance. It would be extrememly helpful if they knew whether the service required a minimum password length of 7 or 8 characters. And, if we change it to 10, we'd like the clients to update automatically.
So, how best to share this information with a client? I've read a number of different options but am curious how anyone here has or would tackle the problem?
Could you consider the information to be retrieved a standard BO and "fetch" it from the server? I'd think a CommandBase derived class could also retrieve the information. Of course, this is assuming everything is CSLA-based. (EDIT: re-read the original post and this probably isn't the case)
If the clients aren't CSLA, then maybe you could host a traditional web service on the same machine and let them make a call to it to retrieve the information.
Yea, we have no control over the clients so I can't trust them to be using CSLA. I should have also mentioned that this is a WCF interface hosted in IIS. Not sure if that matters, but it was missing from my initial explanation.
We had the idea of returning some form of object that contained the values but argued whether this was considered metadata for the service, configuration data, settings, etc. and what would be the right way?
I've seen articles about using ParameterInspectors to validate the parameters on the client, but these are not included in the generated WSDL, so unless you have control over the proxy and can manually add the attribute, the inspector doesn't get attached to the client. I can certainly do this in my SDK, but if someone doesn't use my SDK then they lose the capability of providing client-side validation and, more importantly, the ability to customize/modify their UI based on the server configuration/settings.
A great scenario was just presented to me. One of our devs that is working on the sample application wants to create a custom MembershipProvider that can interface with our service that will enable the built-in security controls in an ASP.NET application. As part of this, we would need a way for the client-side MembershipProvider to obtain the server-side configuration information for properties such as EnablePasswordReset, RequiresUniqueEmail et al. This is not something that the client app can dictate since it is our service that manages application security.
Perhaps this use case will help clarfiy what we are trying to accomplish. Any thoughts?
Copyright (c) Marimer LLC