I have a wcf service in front of an AzMan store that passes roles and operations to clients using the following interface:
[OperationContract]
bool AuthenticateUser(string password, string appName);
[OperationContract]
string[] GetRoles(string storelocation, string appName);
[OperationContract]
string[] GetOperations(string storeLocation, string appName, string selectedRole);
Clients connect to this service using windows authentication (but users must send their password through to reaffirm their identity). Ultimately the service delivers an array of operations that each client can perform based on their selected role.
I've opened a new Silverlight Business Application and tried to understand how authentication/authorization works in this template, as well as scoured the web to find examples to how to hook my webservice to the login box already created in the template, but I am completely at a loss as how to do this!
Can anyone offer any advice?
The Business application template has an AuthenticationService, that is based on the User object and the AuthenticationBase class. AuthenticationBase has virtual methods that you can override to use your own security mechanisms.
For example, there is a Login method, based on a username and a password. This method returns a IUser that has a name and roles.
After looking at your interface, I'd create a sub-interface of IUser to include the list of allowed operations and change the generated User class to implement this sub-interface. And I'd override the Login and related methods in AuthenticationService to use your existing Azman-based code.
Related
From an external application, I am calling a rest web service that is implemented in Jspresso.
In the Jspresso web service, I would like to initialize the environment/context in order to act like a user connected by the login module.
Is there a method to call to initialize the environment (userPrincipal, ...)
Normally, your web services classes should extend org.jspresso.framework.application.startup.AbstractBackendStartup.
Then you can use the following protected methods :
protected Subject createSubject(String userName)
protected void configureApplicationSession(Subject subject, Locale locale)
This will initialize a session with all necessary information.
I have created ASP.net MVC4 application with Internet application template,
and want to add List<T> property to MembershipUser object provided by ASP builtin Forms Authetication.
This List property will be a list of StockPermission object:
public class StockPermission
{
private Stock stock;
private byte afterSaveAction;
private bool allowEditingStockDocs;
private bool allowChangingUser;
}
Therefore my MembershipUser will contain StockPermission objects
which let MembershipUser to perform defined action with those Stocks in the List
Before you start trying to do something like this, it would be wise for you to read up on exactly what these systems are. It's clear from your comments that you don't really understand them because you're confusing multiple systems.
FormsAUthentication has nothing to do with MembershipUser. FormsAuthentication is only about providing a cookie for each web request to be shown as authenticated. FormsAuthentication can be used with any kind of credential system.
MembershipUser is part of the Membership subsystem. Membership has nothing to do with FormsAuthentication, other than your code will call into Membership to validate the users credentials, then your code will create a cookie using FormsAuthentication to log the user in.
The changes you want to make are related to permissions, and permissions are not part of the Membership system, they are part of the Role system. These systems are separate for a reason, because they can be replaced with custom implementations. and they have logically different functionality.
Finally, you can't change the MembershipUser, as it's part of the basic framework. You could extend it by deriving your own class from MembershipUser, but that's not the recommended way to do things. You should, instead, have your own User class which references the MembershipUser.ProviderUserId.
In short, you're about to dig into the internals of the framework. This is not something you should do without understanding more about what this is.
To add List property to our MembershipUser object or any other properties we can create custom MembershipProvider and custom MembershipUser classes describer in this article:
http://msdn.microsoft.com/en-us/library/ms366730(v=vs.100).aspx
I've implemented custom logging logic for WCF service by using IDispatchMessageInspector.
I'm logging entire SOAP request/response in the database by utilizing both AfterReceiveRequest and BeforeSendReply.
I'm using claims-based authentication which works without any issues.
However, when I attempt to access Thread.CurrentPrincipal.Identity.Name or ClaimsPrincipal.Current.Identity.Name, I get empty string always (identity is not set, thus name is blank).
Is there a way to access the identity in any way from IDispatchMessageInspector?
Thank you!
If your claim-based authentication is working, you could add the user to your claimset.
You can access your ClaimSet in a static way:
ReadOnlyCollection<ClaimSet> claimSets = ServiceSecurityContext.Current.AuthorizationContext;`
The other possibility is adding a ServiceAuthorizationManager to your service, register it in your configuration and access your ClaimSet from this class.
Hope this helps
I have a wcf 4.0 service , I am running it locally in IIS express and am using azman to manage security. I am able to use the declarative syntax to secure the services, and prevent class instantiation in a class library. However when I decorate a method in the class it has no effect.
[PrincipalPermission(SecurityAction.Demand, Role = "AdminRole")] //THIS WORKS
public class MaintainUser
{
[PrincipalPermission(SecurityAction.Demand, Role = "CreateNewUserx")] //THIS DOES NOT WORK
public void CreateNewUser()
{
if (ViterraSecurity.VerifyAccess.HasOperation("CreateNewUserx", ViterraSecurity.VerifyAccess.BasisOperations.CreatUser))
{
return;
}
throw new AccessViolationException("CreateNewUser");
}
}
Is it possible to enable security checks on methods?
I'm guessing that CreateNewUserx is an operation or task in AzMan, not a role. AuthorizationStoreRoleProvider only recognizes AzMan roles, and PrincipalPermission only checks the roles exposed by an IPrincipal. However, this is a bit of a backwards way of using AzMan, since the main point of an operations-based authorization mechanism is to allow roles to be user-configurable and allow the application to only worry about operations.
I would recommend scrapping your demands for roles in favour of demanding only operation permissions. With such an approach, you would need to change either your permission (and attribute) or your principal implementation, or both to be aware of AzMan operations.
It seems like I'm barking up the wrong tree when asking this question, this question and this question.
I need to authenticate users against a custom API (in COM), and I need to keep that custom API (the COM object) alive (for that user) for future WCF calls. During authentication against that custom API, I can get back a list of custom-defined roles. I'd also like to use these for authorization of the service methods.
Moreover, I need to be able to revoke the user's session remotely. This is triggered by an event raised by the COM API.
I've got a custom UserNamePasswordValidator, but it appears that this has no mechanism for correctly setting a custom principal, so it looks like I'm heading in the wrong direction.
How do I do these three things?
You can handle authentication completely in your service. Create service contract similar to:
[ServiceContract(SessionMode=SessionMode.Required)]
public interface IService
{
// All your operations marked with [OperationContract(IsInitiating=false, IsTerminating=false)]
// Two additional operations
[OperationContract(IsInitiating=true, IsTerminating=false)]
void Login(string user, string password);
[OperationContract(IsInitiating=false, IsTerminating=true)]
void Logout();
}
Service implementing this contract has to have PerSession instancing. Implement authentication in Login method and store COM object in local field. When new client want to use such service he has to first call the Login method. So all your instances will be properly authenticated and they will store their instance of COM object.
You can also register InstanceContext and COM object to some global class which will deal with forcibly killing service instance. This will probably require some research to make it work.
Make sure that you use some secure binding (encryption) because you will send user name and password as a plain text.