We Keep Coding

How do I send Phishing Protection API key over gRPC?

I am trying to use Google Phishing Protection API over gRPC, everything seems straight-forward looking here, but comparing to here you can see that using REST you can send a request without authenticating or some-such, rather you can pass an API key as a query param.
I tested the REST option and it works for me, but trying to use the gRPC option I get failures while trying to authenticate, which I do not want to do.

The equivalent of the REST key query parameter in gRPC is the x-goog-api-key metadata. The API to add that metadata key will vary by language.
When using Java with the googleapi client (which you should be using), you can use:
PhishingProtectionServiceV1Beta1Client.create(
PhishingProtectionServiceV1Beta1Settings.newBuilder()
.setCredentialsProvider(new NoCredentialsProvider())
.setHeaderProvider(PhishingProtectionServiceV1Beta1Settings.defaultApiClientHeaderProviderBuilder()
.setApiClientHeaderKey(yourApiKey)
.build())
.build());
In "plain" grpc it would look more like:
import io.grpc.Metadata;
private static final Metadata.Key<String> API_KEY
= Metadata.Key.of("x-goog-api-key", Metadata.ASCII_STRING_MARSHALLER);
Metadata apiKeyMetadata = new Metadata();
apiKeyMetadata.put(API_KEY, yourApiKey);
stub = stub.withInterceptors(MetadataUtils.newAttachHeadersInterceptor(apiKeyMetadata));

Talking about gRPC it is understandable that you are required to authenticate. It is necessary for quota

Amazon Cognito developer authenticated identity with Java SDK

I am trying to authenticate a java app to AWS services using a developer-authenticated Cognito identity. This is very straightforward in the AWS mobile SDKs (documentation), but I can't seem to find the equivalent classes in the Java SDK.
The main issue I am having is that the Java SDK classes (such as WebIdentityFederationSessionCredentialsProvider) require the client code to know the arn of the role being assumed. With the mobile SDK, it uses the role configured for the federated identity. That's what I'd prefer to do, but it seems the Java SDK doesn't have the supporting classes for that.

The last comment from Jeff led me to the answer. Thanks Jeff!
String cognitoIdentityId = "your user's identity id";
String openIdToken = "open id token for the user created on backend";
Map<String,String> logins = new HashMap<>();
logins.put("cognito-identity.amazonaws.com", openIdToken);
GetCredentialsForIdentityRequest getCredentialsRequest =
new GetCredentialsForIdentityRequest()
.withIdentityId(cognitoIdentityId)
.withLogins(logins);
AmazonCognitoIdentityClient cognitoIdentityClient = new AmazonCognitoIdentityClient();
GetCredentialsForIdentityResult getCredentialsResult = cognitoIdentityClient.getCredentialsForIdentity(getCredentialsRequest);
Credentials credentials = getCredentialsResult.getCredentials();
AWSSessionCredentials sessionCredentials = new BasicSessionCredentials(
credentials.getAccessKeyId(),
credentials.getSecretKey(),
credentials.getSessionToken()
);
AmazonS3Client s3Client = new AmazonS3Client(sessionCredentials);
...

If that's the route you want to go, you can find this role in the IAM console, named Cognito_(Auth|Unauth)_DefaultRole. These are what Cognito generated and linked to your pool, and you can get the ARN from there.
This blog post may be of some assistance. All of the APIs the SDK uses to communicate with Cognito to get credentials are exposed in the Java SDK, you just need to use your own back end to get the token itself. Once you have it, you can set the logins the same way you normally would with another provider and it'll all work.

How to manually set access tokens on OAuthRestTemplate, spring-security-oauth?

I am trying to call an api that uses Oauth 1a using OAuthRestTemplate from spring-security-oauth.
I saw that most of the examples set the consumer key and secret and then let the library get the access tokens.
I have the token and the token secret (which do not expire) and I want to set them on the OAuthRestTemplate and make calls, without going through the authentication flow.
Is that possible? if so, how?

AFAIK that's not possible (it is on the OAuth2 side but OAuth1 never got as much love). Contributions gratefully accepted.

This is possible, though a bit hacky. Example code below:
// Assume you have a preconfigured RestTemplate
OAuthRestTemplate template = new OAuthRestTemplate(resource);
OAuthConsumerToken accessToken = new OAuthConsumerToken();
accessToken.setAccessToken(true);
accessToken.setResourceId(template.getResource().getId());
accessToken.setValue(ACCESS_TOKEN);
OAuthSecurityContextImpl securityContext = new OAuthSecurityContextImpl();
securityContext.setAccessTokens(new HashMap<>());
securityContext.getAccessTokens().put(accessToken.getResourceId(), accessToken);
OAuthSecurityContextHolder.setContext(securityContext);
Ideally, you should check whether an existing security context exists, and add the token to the map if it's not already present.

Simple Kerberos client in Java?

Applications such a Google's Chrome and IE can transparently handle Kerberos authentication; however I can not find a "simple" Java solution to match this transparency. All of the solutions I have found require the presence of a krb5.conf file and a login.conf file which nether of the above apps seem to require.
What is the best way to build a Java application with Kerberos SSO capabilities that just work?
[update]: to be clear I need a CLIENT side solution for creating tickets not validating them. Also, it seems that SPNEGO is the default "wrapper" protocol that will eventually delegate to Kerberos but I need to be able to handle the SPNEGO protocol as well.

There is now a simple solution for this using the Apache HTTP Components Client 4.5 or greater. This is still marked as experimental in 4.5 so your milage may vary, but this is working fine for me in an enterprise context.
In addition to the HC 4.5 client jars you will need to have the httpclient-win, jna and jna-platform jars on your classpath, as provided with http-component-client. You then construct a Kerberos enabled HC-client as follows:
CloseableHttpClient httpclient = WinHttpClients.createDefault();
Or using the builder:
HttpClientBuilder clientBuilder = WinHttpClients.custom();
Which can then be customised as required before building the client:
CloseableHttpClient client = clientBuilder.build();
This solution works without any external configuration, and most importantly solves the issue where the in-built JRE mechanism breaks for users with local Admin rights on Windows 7+. This is possible because the Kerberos ticket is being retrieved directly from the SSPI API via JNA, rather than going through the GSSAPI provided by the JRE.
Example code from the http-components team
This was all made possible by the good work of Daniel Doubrovkine Timothy Wall
and Ryan McKinley

Adding to David Roussels answer on url specific http based kerberos authentication:-
The reason why your code works is because your target SPN(server side principal) is configured to with HTTP/serverhostname.realm.com#DOMAIN.COM. In that case it will work because you are not explicitly setting the token. URLConnection internally sets a token with that SPN
1 Perform steps(from my previous answer) to get a subject
2 Use gss api init sec context to generate a context token. There are numerous tutorials out there for this step
3 Base 64 encode the token
4 Attach the token to urlconnection:-
URL url = new URL("http://myhost/myapp")
HttpURLConnection urlConn = (HttpURLConnection)url.openConnection(); =
urlConn.setRequestProperty("Authorization", "Negotiate " + encodedToken);
5 Implement a priviledged action:-
//this internally calls the getInputStream
public class PrivilegedGetInputStream implements PrivilegedExceptionAction<InputStream>
6 Wrap the whole thing in Subject.doAs
//use prev answer instructions to get subject
Subject.doAs(subject, new PrivilegedGetInputStream(urlConnection)

Oracle has an example using Java's SaslClient. I'm not a Java programmer, but when I pointed this out once to someone who is, they were able to make it work pretty quickly. It may still require a "conf" file somewhere (n.b. Kerberos uses environment variables, often starting with KRB5_, to know where to look for such files). Also note that Kerberos itself does not include a transport of any kind--your app needs to know how to send and receive the Kerberos payloads the way the server expects (and this is different depending on the server you are trying to authenticate with).
Edit: you edited your question, so here's a link related to SPNEGO in Java which might be of some use:
http://download.oracle.com/javase/6/docs/technotes/guides/security/jgss/lab/part5.html

You don't actually need to do anything. In Java 6, on a Windows client machine you can do this:
new URL("http://myhost/myapp").openStream();
And negotiate authentication just works. At least it does for me. And the server I tested on only supports Negotiate, not NTLM auth.

Ok if you want to avoid using a login.conf file you need to code differently:-
//define your own configuration
import javax.security.auth.login.Configuration;
public class CustomLoginConfiguration extends Configuration
//pass certain parameters to its constructor
//define an config entry
import javax.security.auth.login.AppConfigurationEntry;
private AppConfigurationEntry configEntry;
//define a map of params you wish to pass and fill them up
//the map contains entries similar to one you have in login.conf
Map<String, String> params = new HashMap<String, String>();
//define the configuration
configEntry = new AppConfigurationEntry(
"com.sun.security.auth.module.Krb5LoginModule",
AppConfigurationEntry.LoginModuleControlFlag.REQUIRED, params);
//implement getappconfig method
public AppConfigurationEntry[] getAppConfigurationEntry() {
return new AppConfigurationEntry[] { configEntry };
}
Now once you are done with this definition you can use this in you use this to fetch tickets from kdc
//get ticket in login context
LoginContext lc = null;
lc = new LoginContext("lc", null, callback, new CustomLoginConfiguration(argumentlist));
lc.login();
Now from here on you can fetch jaas subject and can basically do a ton of authentication stuff.
In case you need further pointers just leave a comment.

You can use system properties instead of config files to specify the KDC hostname and service name, but those things (at least) are mandatory....
Waffle will actually give you the information you need to set most of the properties, even if it won't get you a ticket. Look at the WindowsAuthProviderImpl class (the Waffle.chm help file shows the API).
I use JAAS do obtain a service ticket from Active Directory in two steps:
Use Krb5LoginModule to retrieve the cached TGT and add it to the Subject.
Use the Subject and GSS-API to retrieve a service ticket from the KDC.
There's a lot of good information and example code at The Java Way of Active Directory.

I created a small tool to simplify connecting with httpclient to kerberos, you might want to give it a try.
https://github.com/DovAmir/httpclientAuthHelper
DefaultHttpClient httpclient = new DefaultHttpClient();
AuthUtils.securityLogging(SecurityLogType.KERBEROS,true);
CredentialsUtils.setKerberosCredentials(client, new UsernamePasswordCredentials("xxx", "xxx"), "domain", "kdc");
client.executeMethod(httpget);

Use WAFFLE

Here's a good blog post on having a java client to use with Kerberos
http://sachithdhanushka.blogspot.com/2014/02/kerberos-java-client-configuration.html

2-legged OAuth with google-api-java-client

Does anyone know how to use 2-legged OAuth with google-api-java-client?
I'm trying to access the Google Apps Provisioning API to get the list of users for a particular domain.
The following does not work
HttpTransport transport = GoogleTransport.create();
GoogleHeaders headers = (GoogleHeaders) transport.defaultHeaders;
headers.setApplicationName(APPLICATION_NAME);
headers.gdataVersion = GDATA_VERSION;
OAuthHmacSigner signer = new OAuthHmacSigner();
signer.clientSharedSecret = CONSUMER_SECRET;
OAuthParameters oauthParameters = new OAuthParameters();
oauthParameters.version = OAUTH_VERSION;
oauthParameters.consumerKey = CONSUMER_KEY;
oauthParameters.signer = signer;
oauthParameters.signRequestsUsingAuthorizationHeader(transport);
I get the "com.google.api.client.http.HttpResponseException: 401 Unknown authorization header".
The header looks something like this
OAuth oauth_consumer_key="...", oauth_nonce="...", oauth_signature="...", oauth_signature_method="HMAC-SHA1", oauth_timestamp="...", oauth_version="1.0"
I also tried following without success
GoogleOAuthDomainWideDelegation delegation = new GoogleOAuthDomainWideDelegation();
delegation.requestorId = REQUESTOR_ID;
delegation.signRequests(transport, oauthParameters);
Any ideas?
Thanks in advance.

It seems that there was nothing wrong with the code. It actually works.
The problem was with the our Google Apps setup.
When you visit the "Manage OAuth key and secret for this domain" page (https://www.google.com/a/cpanel/YOUR-DOMAIN/SetupOAuth),
and enable "Two-legged OAuth access control" and select
"Allow access to all APIs", it doesn't actually allow access to all APIs.
If you visit the "Manage API client access" page after that
(https://www.google.com/a/cpanel/YOUR-DOMAIN/ManageOauthClients),
you'll see that there is an entry like:
YOR-DOMAIN/CONSUMER-KEY "This client has access to all APIs"
It seems that this doesn't include Provisioning API.
Only after we explicitly added the Provisioning API, the code started to work.
So to enable Provisioning API, you should also have something like the following entry in your list:
YOR-DOMAIN/CONSUMER-KEY Groups Provisioning (Read only) https://apps-apis.google.com/a/feeds/group/#readonly
User Provisioning (Read only) https://apps-apis.google.com/a/feeds/user/#readonly
Somone else had the same problem:
http://www.gnegg.ch/2010/06/google-apps-provisioning-two-legged-oauth/
Sasa

Presumably you are trying to get an unauthorised request token here? I Haven't used the Google implementation, but the OAuth 1.0a spec says you need a callback URL, which you don't have. This might be a red herring as the spec says a missing param should return HTTP code 400 not 401.
See http://oauth.net/core/1.0a/#auth_step1