There are situations where resource creation requires more than one step.
Example
A session resource is created when a user authenticates. So the API call responsible for authentication would be a POST to example.com/api/sessions.
We use a password-authenticated key exchange for authentication. This requires the sending of two messages to the server: AuthInit and AuthFinish. The session should only be created once the user is authenticated (after successful processing of AuthFinish).
But since there are now two steps to creating a session, where should each of the two requests be send?
Potential Solution 1: two endpoints
AuthInit -> example.com/api/sessions/init
AuthFinish -> example.com/api/sessions/finish
Potential Solution 2: one endpoint handles both
AuthInit -> example.com/api/sessions
AuthFinish -> example.com/api/sessions
Related
I'm currently working on a backend infrastructure and I could need some advice.
First, here is the current global architecture:
I have WCF services hosted in IIS
I have multiples databases hosted on SQL Server. One ClientData database per client and one global MasterDatabase.
MasterDatabase contains a mapping of credentials associated to a connection string. That database allows me to use the appropriate ClientData database (via Entity Framework) depending on the credentials provided.
I'm using Basic Auth over SSL.
Credentials verification are done in overridden method checkAccessCore() in my ServiceAuthorizationManager subclass. Inside that method, I fetch MasterDatabase, ensure credentials are correct (password are saved in DB using Bcrypt) and retrieve the connection string.
Once the connection string is retrieved, I create an instance of my class CustomIdentity that inherits from GenericIdentity. Using that instance I can then set the Thread.CurrentPrincipal property.
Each WCF service implementation retrieves the connection string from the CustomPrincipal in order to fetch data from the appropriate ClientData database.
My questions/thoughts are the following:
If I decide to use concurrency in my WCF services, how will I handle that due to the fact that CheckAccessCore is a method of a WCF extension that force concurrent operations to run sequentially?
http://support.microsoft.com/kb/KbView/2907010
This means that all my call will be enqueued and blocked at the checkAccessCore level.
Overriding checkAccessCore is the best way I found to intercept calls early in the call stack in order to verify user credentials.
Should I use a different way to transport the client connection string other than over the custom identity? Is it secure?
If I use concurrency, I guess the identity set into the CustomPrincipal will be overridden. If yes, how to handle that?
I'd like to enable OAuth1 Provider support on my restful web service. Jersey supports this as described here Jersey OAuth1 Provider support.
I've been trying to register it as so:
public ApplicationConfig(){
super();
addRestResourceClasses(getMyResourceClasses());
register(new OAuth1ServerFeature(new DefaultOAuth1Provider(),"/oauth/access_token","/oauth/request_token"));
}
But, when I register the OAuth1ServerFeature, I get a 404 when trying to access my resources.
Can't seem to find any examples/tutorials implementing jersey oauth support anywhere!
Is there a simple component I can plug into my jax-rs service to enable oauth support?
I realise this thread is somewhat old - but having just got it work myself, I felt a reply was in order! Given time, I may even create a blog post with a fuller example. Be warned - this is not a short answer!
There is an absolute lack of examples on information on using the OAuth1 server (aka Provider) feature in Jersey - I can't remember a tech topic that revealed so little useful Google information. I almost passed on looking for another solution since it led me to think perhaps it didn't work. But, with some perseverance, I can say that not only is it usable, but it seems to work rather well. Plus of course, if you're already using Jersey for your REST API - you don't need any extra libs.
I am not an OAuth1 expert - and I'd strongly recommend some background reading for those attempting this. I am also assuming here you have Jersey working, understand things like ContainerRequestFilters, and also have some internal means to authorize users.
My examples also use the excellent JAX-RS OSGi connector - the only real difference is that where we use an OSGi bundle context to register the OAuth1 feature via an OSGI service, regular Jersey users will need to configure via their normal Application / Server config model.
Initialisation
You must create your OAuth1 feature - and give it a provider:
DefaultOAuth1Provider oap = new DefaultOAuth1Provider();
Feature oaFeature = new OAuth1ServerFeature(oap, "oauth1/request_token", "oauth1/access_token");
Don't forget to register oaFeature into Jersey!
The DefaultOAuth1Provider is entirely memory based - which was fine for us to start with. Many will want to persist access tokens for use across server restarts, which will require an extended subclass (or clean implementation)
Add in your Consumers Keys and Secrets
It took me a while to realise Consumers were not users but clients i.e. applications. The Jersey implementation will not work if you don't register keys and secrets for each consumer (aka client app) that wishes to connect
oap.registerConsumer("some-owner-id",
"abcdef" ,
"123456",
new MultivaluedHashMap<String,String> ());
You obviously would never hard-code these, and further would use some form of secure store for the secret (param 3).
If you do not add these you will not get any further.
OAuth protocol step 1 - get a request token
At this stage you are ready client side to get a request token - and here there is a perfectly good example on GitHub.
ConsumerCredentials consumerCredentials = new ConsumerCredentials("abcdef","123456");
//TODO - user proper client builder with real location + any ssl context
OAuth1AuthorizationFlow authFlow = OAuth1ClientSupport.builder(consumerCredentials)
.authorizationFlow(
"http://myhost:8080/myapi/oauth1/request_token",
"http://myhost:8080/myapi/oauth1/access_token",
"http://myhost:8080/myapi/oauth1/authorize")
.build();
String authorizationUri = authFlow.start();
System.out.println("Auth URI: " + authorizationUri);
Obviously you would change URLs to point to your server and - crucially - the client needs to use the same Conumer Key and Secret you registered in the server.
You will get back a response with an oauth_token string in it e.g.
http://myhost:8080/myapi/oauth/authorize?oauth_token=a1ec37598da
b47f6b9d770b1b23a5f99
OAuth protocol step 2 - authorize the user
As you will read in any article, actual user Authorization is outside of the scope of OAuth1 - at this stage you must invoke your servers auth process whatever that is.
However!!!! What is not outside the OAuth1 scope is what your server needs to do if the user authorizes successfully. You must tell your DefaultOAuth1Provider about the successful auth:
// Dummy code - make out like we're auth'd
Set<String> dummyRoles = new HashSet<> (Arrays.asList( new String[] { "my-role-1", "my-role-2" }));
DefaultOAuth1Provider.Token tok1 = getRequestToken("a1ec37598da
b47f6b9d770b1b23a5f99");
String verifier = authorizeToken(tok1, new Principal()
{
public String getName()
{
return "my-user";
}
},
dummyRoles);
System.out.println("***** verifier: " + verifier);
Note the request token string is that from step 1. Obviously a real implementation would pass a real Principal and set of roles for the authorized user.
Also, of course, printing out the verifier is not much use - you need to get that back to your client in some way, either via an independent channel or possibly as a header in the auth response - which maybe would need to be encrypted for added protection.
OAuth protocol step 3 - swap the request token for an access token
Once the client receives or has the verifier entered manually, it can finalize the process and swap the request token for an access token e.g.
String verifier = System.console().readLine("%s", "Verifier: ");
final AccessToken accessToken = authFlow.finish(verifier);
System.out.println("Access token: " + accessToken.getToken());
Again, not a realistic example - but it shows the process.
If your OAuth1Provider saves access tokens to some persistent store on the server, you can re-use any access token returned here on a future session without going through all the previous steps.
That's it - you then just need to make sure every request the client creates from this point on in the process makes use of that access token.
I am using Customvalidator class inheriting the UserNamepasswordvalidator
The problem is Its getting called on every request. I want to bypass it once the user is authenticated
any help would be appreciated
There's no way to skip the validator, custom, UserName/Password or certificate based. It's actually called before the request hits your main function, so there's no way to step around it using a session or variable.
And that's really the point of separating authentication from the message processing ... it allows you to reject bogus requests at the earliest stage of the request/response process so your program's not wasting cycles fighting off zombie attacks and the like.
You can, of course, apply no authentication up front in your message processing and authenticate when the request arrives (not before as in the prior model). At that point you can create a session programmatically and go on from there ... but you'll be processing every message that comes through.
I'll add this, however. If think that if you use something like NetTCPBinding, or NetNamedPipesBinding, you can create a persistant session between the client and host, thus authenticating only once.
Architecture of project
my wcf expose 11 endpoints,one of the endpoint ment for authentication and autherization. which returns the accountid of the user.this accountid is sent by client in every method for recozination.
need
i dont want to send the account id to every method ,all i want a way that can give me the accoint id automatically if the client is loggedin
Limitation...
1> i cant use membership.
2>i can,t use persession mode of wcf becose it creates new session for every endpoint
3> cant use outgoinfheaders on client side ..
is there any custom way to solve this problem
That looks like scenario for federated security but it would conflict with some of your requirements.
You don't need membership.
You don't need per session services
You need somehow pass the token - if you cannot use custom outgoing SOAP header and configure it in some central place, you will have to pass the token inside the message body and you will have to configure it as a parameter for each service call.
I'm creating a smart client application using .NET 3.5. A Winforms client connecting through WCF services to retrieve data from SQL Server 2008. I need to pass a username/password (encrypted and over HTTPS) and return information such as:
Is this user (e-mail address) under a current subscription
What server should we go to next for all subsequent calls (poor man's load balancing)
What server/database should be used in the connection string (credentials not required), as people could be using different databases depending on their subscription, etc.
So my first call when signing on sends the credentials which a lookup is performed. A serializable class will be used to create a token object (I assume this is the way to handle this) which will return the expiration, server info, database info.
The question is on all subsequent calls do I pass this token as a parameter to every service contract (web method) or can I leave all my current contracts as is and pass the token in a header or some other more universal method?
How do you suggest implementing a token system such as I describe?
Thank you
For one, I would only return a TokenID - some unique ID to clearly identify the user and his subscription in question - from your first "authentication" call. No need to send back and forth the whole set of information all the time - only the service on the server side needs those details, so you can leave that info on the server and only consult it in your server code when needed.
So that first call - the authentication call - would most likely check the credentials being sent against a database table, against a subscription table, and then put that information (who's calling in, based on what subscription) and possibly some kind of an expiration date/time into a "Valid Callers" table and generate an ID from that (a GUID or something). You might want limit the "lifespan" of a TokenID - e.g. it's valid for 30 minutes or so - so that it can't be hijacked and used perpetually after a first successful call. That generated GUID is then returned as the TokenID from the Authentication call and can be used as an identifier in each subsequent call.
Things like what database server to use have really no place in messages going back and forth - they're strictly important to the server-side service code - just leave it there!
It is definitely preferred practice to put such "meta information" that isn't the real value information for your calls into headers and go search for it there. WCF supports this quite nicely and easily - with either message inspectors (sample for that here and here) on client and service side, or by using the OperationContextScope (sample blog post here and here) - both work just fine.