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.
Related
Hope everyone keeping safe,
I am trying to understand some of the abstractions in asp.net core authentication / authorization (and browsing the source code for additional insight).
There is an abstraction called "AuthenticationScheme" which seems to only bring in a ‘name’ property to the actual IAuthenticationHandler (which seems to be is the type that does the work).
I am trying to understand why asp.net has this the scheme abstraction, if the intent is just to give the handler a name, why not just include a name property in the handler's interface definition ?
To allow usage of the handler multiple times at least.
If you make an API that allows JWT Bearer tokens from two identity providers, then you might want to specify the JWT Bearer authentication handler twice.
And since each handler needs a unique name so we can invoke the right one, the developer must define those names.
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.
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'm wondering how I can restrict some methods from unauthorized user access. Let's assume I have a WCF service with the following contract:
int Login(string username, string password);
Invoice[] GetCustomersInvoices(int customerId);
A user should act in the following way:
Login to verify against the service and get his custumerId
fetch his invoices by invoking the corresponding method with his customerId
Well, that's maybe a stupid question, but what if customerA's id is 23, but somehow customerA knows customerB's id, which is 42. Now customerA could read customerB's secret invoice data...
What could I best do to avoid this?
You shouldn't use a single id for identifying someone. There are many ways of enabling authn/authz in WCF, I like the article at http://msdn.microsoft.com/en-us/magazine/cc948343.aspx for a good introduction on some ways of doing it.
Your current approach of calling methods will only work if you are able to implement secure(persistent) channel between client and server using SSL or any other such mode (typical scenario would be Baking Payments Getaways)
So IMO you need to implement your user authentication inside the method (no separate calls). i.e. you have to pass userid and password along with invoiceid to GetCustomersInvoices() method and inside it you need to authenticate the user and retrieve the data.
Following would be solution for such scenario,
Implement your own User Name Password Validations (custom usernameathentication), which will first authenticate the user and than it will call the method given. Since this will happen in one request so it will solve your problem.
Typical service method call would be like,
Service.UserName = "abc"
Service.Password = "***"
Service.GetInvoiceDetails(1233)
You can get the use of Message Headers and Body to pass your custom values, Webservices support such scenario where you can pass encrypted data in SOAP headers.
Alternatively you can use Certificates also, but these are not free.
In general you can go through following links to get more info in various kinds of security WCF supports,
http://msdn.microsoft.com/en-us/library/ms731925.aspx
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.