I am setting authentication manually in my application using PreAuthenticatedAuthenticationToken. But I keep getting error as follows,
No bean named 'org.springframework.security.authenticationManager' is defined: Did you forget to add a gobal element to your configuration (with child elements)?
I don't have a UserDetailsService as it is not required for me. Please help me on how to configure authentication manager ?
You are missing an <authentication-manager> element. You need to have one which processes the PreAuthenticatedAuthenticationToken, usually adding any relevant roles for the user. If you want it to be a no-op operation, then that's fine, but it still has to be there, so you can either implement a simple UserDetailsService which just returns a user object with a fixed role, or you can implement AuthenticationProvider directly and create the final token in its authenticate method, however you want to do it. Either way, the configuration would be similar to the one described in the user manual.
Related
I'm working with the use case published on http://wso2.com/library/articles/2010/10/using-xacml-fine-grained-authorization-wso2-platform/ and it works well but I need to customize the XACML query with Action, Resource and Subject fields.
When I add the Entitlement Mediator to ESB I am not able to add these arguments (which are stored in properties elements on ESB). How can I specify Action, Resource and Subject to construct the XCAML query before sending to IS?
Thanks in advance,
Joan
In entitlement mediator has call back handler where you can implement a way to pick those Action, Resource and so on. By default handler, picks as following
Resource --> Incoming message "To" soap header
Subject ---> if your proxy service is secured with UT and Basic auth, it would pick the authenticated user name
But you can write your own handler and plug it with entitlement mediator, there are some available handler implementations. You can refer this [1] for more details
[1] http://nallaa.wordpress.com/2013/07/25/entitlement-mediator-with-wso2-enterprise-service-bus-esb/
It is fine to use ESB 4.8.0 it would be release soon. However there is no UI in 4.7.0 to configure them. But you can do it using synapse configuration. Say you want to add new custom call back class. you can add it as follows
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 am creating a custom STS using a custom UserNameSecurityTokenHandler derived class. In the client, I am adding some additional information to the AdditionalContext property of the RequestSecurityToken that the Token Handler needs to fully authenticate (in addition to User Name & Password).
I assume that the RequestSecurityToken must be available to me somewhere in my Token Handler, but I cannot locate it. I've prowled through the code with Reflector, but that has not helped either.
How can I get at this information?
Thanks in advance.
David Mullin
It turns out that I was confusing two unrelated things. The UserNameSecurityTokenHandler class is for authenticating the UserName/Password Client Credentials, which then flows into the STS as the "Current Principal".
So, never mind.
im using a WCF service with the users and roles being kept in the database. In my service im trying to identify whose calling the service. So i type in my WCF service
string user = ServiceSecurityContext.Current.PrimaryIdentity.Name;
but i get i nullexception object not sent to an reference, ive tried googleing it all day but cant seem to find whats wrong. Any suggestions ?
"What's wrong" is that ServiceSecurityContext.Current is returning null rather than an instance of ServiceSecurityContext.
One scenario where this occurs is if the binding is configured to use Message security with MessageCredentialType set to None.
However, I'm not aware of any comprehensive documentation listing every scenario where ServiceSecurityContext.Current can be null: as the security context is established in the channel stack it is something which depends on the specific binding configuration and security providers in use. It could also, I imagine, be affected by custom Behaviors which fiddle with message properties.
Having said that, unless you have custom code inserted into the channel stack, it is probably a safe assumption that this will only occur in cases where the binding does not require any client authentication. You should check first of all that you are using a binding configuration which will auhenticate the client and provide the kind of user name IIdentity you are expecting.
I'm looking for some input for a challenge that I'm currently facing.
I have built a custom WIF STS which I use to identify users who want to call some WCF services that my system offers. The WCF services use a custom authorization manager that determines whether or not the caller has the required claims to invoke a given service.
Now, I'm building a WPF app. on top of those WCF services. I'm using the MVVM pattern, such that the View Model invokes the protected WCF services (which implement the Model). The challenge that I'm facing is that I do not know whether or not the current user can succesfully invoke the web service methods without actually invoking them. Basically, what I want to achieve is to enable/disable certain parts of the UI based on the ability to succesfully invoke a method.
The best solution that I have come up with thus far is to create a service, which based on the same business logic as the custom authorization policy manager will be able to determine whether or not a user can invoke a given method. Now, the method would have to passed to this service as a string, or actually two strings, ServiceAddress and Method (Action), and based on that input, the service would be able to determine if the current user has the required claims to access the method. Obviously, for this to work, this service would itself have to require a issued token from the same STS, and with the same claims, in order to do its job.
Have any of you done something similar in the past, or do you have any good ideas on how to do this?
Thanks in advance,
Klaus
This depends a bit on what claims you're requiring in your services.
If your services require the same set of claims, I would recommend making a service that does nothing but checks the claims, and call that in advance. This would let you "pre-authorize" the user, in turn enabling/disabling the appropriate portions of the UI. When it comes time to call your actual services, the user can just call them at will, and you've already checked that it's safe.
If the services all require different sets of claims, and there is no easy way to verify that they will work in advance, I would just let the user call them, and handle this via normal exception handling. This is going to make life a bit trickier, though, since you'll have to let the user try (and fail) then disable.
Otherwise, you can do something like what you suggested - put in some form of catalog you can query for a specific user. In addition to just passing a address/method, it might be nicer to allow you to just pass an address, and retrieve the entire set of allowed (or disallowed, whichever is smaller) methods. This way you could reduce the round trips just for authentication.
An approach that I have taken is a class that does the inspection of a ClaimSet to guard the methods behind the service. I use attributes to decorate the methods with type, resource and right property values. Then the inspection class has a Demand method that throws an exception if the caller's ClaimSet does not contain a Claim with those property values. So before any method code executes, the claim inspection demand is called first. If the method is still executing after the demand, then the caller is good. There is also a bool function in the inspection class to answer the same question (does the caller have the appropriate claims) without throwing an exception.
I then package the inspection class so that it is deployed with clients and, as long as the client can also get the caller's ClaimSet (which I provide via a GetClaimSet method on the service) then it has everything it needs to make the same evaluations that the domain model is doing. I then use the bool method of the claim inspection class in the CanExecute method of ICommand properties in my view models to enable/disable controls and basically keep the user from getting authorization exceptions by not letting them do things that they don't have the claims for.
As far as how the client knows what claims are required for what methods, I guess I leave that up to the client developer to just know. In general on my projects this isn't a big problem because the methods have been very classic crud. So if the method is to add an Apple, then the claim required is intuitively going to be Type = Apple, Right = Add.
Not sure if this helps your situation but it has worked pretty well on some projects I have done.