I've built a JHipster application with oauth2 authentication. The latter is implemented by Keycloak through the generated docker-compose file.
Everything works fine in the browser for "human" users. But I need to make some external programs use the API while beng authenticated.
So I started to simulate direct access to API with Postman. I read about XSRF-TOKEN cookie. But to be frank, I don't understand the process of authentication.
Can anyone explain how to perform authenticated requests to the JHipster API regarding keycloak ?
Maybe it isn't the appropriate approach : I also read about implementing a Configuration based on another authentication mecanism, that should be used for controllers exposed on a different endpoint.
Any help figuring out all of that would be really appreciated !
You need machine to machine authentication. Generally Open ID Connect (OIDC) offers client credentials flow for this case. So in theory you just enable it in the Keycloak client configuration and you may use it. But it depends on your API auth implementation. Your API very likely uses different OIDC flow for humans and it may not be ready for client credentials flow.
I got it working: Jan's tip show me the way.
Mainly I followed this tutorial.
The solution would be to add a client configured with Standard flow, Service account and Authorization enabled. Then I added the JHipster client scope provided by the generated docker-compose setup.
Once that was configured, I configured the request to use the Oauth2 authentication. I filled the configuration form for token request according to the tutorial. And I was good to go !
Many thx !
Related
So, I understand how OIDC works for the most part. I know how to solve this question if we use OIDC directly (without AWS handling it for us). The browser would just send their access_token to us for all async calls, and we could verify it against the OIDC UserInfo service that's hosted by our OIDC provider.
The AWS implementation doesn't expose any of these common OIDC values to the browser though, and just gives us their proprietary encrypted cookies like AWSELB. This is fine, for super basic sites where you don't care about actually authenticating the user once they're authorized, but we care about both.
We could also generate a proprietary "session key" when our callback is hit, and use that instead of the AWSELB cookie... but it seems like reinventing the wheel. Certainly, there must be a way to let our backend application code just reuse the AWSELB cookie to verify the identity of user? AWS documentation mentions no such webservice to allow us to validate that cookie from our server code.
The load balancer provides the IdP's access token as a header: x-amzn-oidc-accesstoken; you should be able to validate this against the IdP. It also provides user claims in a header: x-amzn-oidc-data.
See https://docs.aws.amazon.com/elasticloadbalancing/latest/application/listener-authenticate-users.html#user-claims-encoding
Subscription based iOS app I'm building uses Cloud Run service invoked via HTTPS request.
How can I make sure that the request can only be invoked by app owners(from the app)?
I've looked at Google Sign-In authentication, but I don't think it is applicable in my case as only those subscribed to the app should have the access, not just those with Gmail account.
I think without a Google Sign-in involved, your question has nothing to do with Cloud Run and can be generalized as:
How to send requests to to a backend app only from its mobile app?
So I'll answer that.
You'll find out that you need some form of "authentication" to prove that you're on a mobile app as a "user". To achieve that, you need some form of sign-in.
You may try to ship a secret (like a token or private key) in the application and use that to authenticate, but this will be susceptible to:
exfiltration of the private they from the application bundle through reverse engineering
applying a man-in-the-middle attack to the HTTPS request (and therefore the token) by trusting a root CA on the device and using e.g. mitmproxy to decrypt the request as plaintext.
In reality, there's no way to fully secure iOS/Android <=> backend communication that. Even the largest apps like Twitter, Instagram etc have their APIs reverse engineered all the time and invoked from non iOS/Android clients as the requests can be spoofed.
If you want to authenticate your existing users, you should figure out how these people login to your app. This could be simple username:password in Authentication: Basic [...] header, or something more complicated like OAuth2 which is what apps like Facebook, Twitter implement under the covers for their mobile apps.
Then you would validate that Authentication header in your Cloud Run application code yourself.
So again, I don't think this is a problem specific to Cloud Run, or any cloud provider.
If your goal is for your API to only be called when your users are authenticated in your app, I would recommend implementing one of the two solutions described on this page:
Using Google Sign-in or Firebase Authentication
I have problems about JWT authentication. Using devices can't use JWT for specification of devices.
And then, I can connect to gateway on Google Console(Test environment) and use sample code of Google.
*cloudiot_mqtt_example.py
*gateway_demo.py
However, I don't know how to confirm NO JWT-auth.
I checked Stackdriver logging but I can't get logs for solving problem.
I can checked to send publishing data via gateway to devices and Cloud Pub/Sub. However, I need to know other method because using test environment can connect JWT and NO JWT.
I debugged source code above URL. This code is definitely via get_client.
def get_client(
~
client.username_pw_set(
username='unused',
password= create_jwt (
project_id, private_key_file, algorithm))
This create_jwt make token.
I think this source programs are using JWT authentication. Would you like to tell me how to check JWT authentication?
I wouldn't recommend connecting without a JWT , but you can check the JWT by printing it out and going to JWT.io and see if it matches your project specifications.
If you can't connect using a JWT then you might be providing the wrong setup information or your private key is wrong so the authentication of the JWT is wrong.
I have various RESTful Web Servicesin App Engine, which are secured Google Account authentication:
<security-constraint>
<web-resource-collection>
<web-resource-name>Authentication required</web-resource-name>
<url-pattern>/api/*</url-pattern>
</web-resource-collection>
<auth-constraint>
<role-name>*</role-name>
</auth-constraint>
</security-constraint>
Upon hitting these Web Services via a browser client, I'm redirected to the Google Accounts login screen where I authenticate myself first before proceeding with the REST call.
However I now need to run these web service via a command line scripts as part of automated IC run. Therefore I do not want to be prompted for a browser login every time. Preferably I would like to put the Google username and password in a encrypted file on the IC server and let it call the Web Services without any human intervention. As far as I can see there are several options:
manually logging in via the browser and then saving the access token to be used in the command line script. However when the token expire I would have issues.
obtain a access token via Service Account p12 authentication. This seems to only work for accessing Google APIs such as BigQuery and Cloud Storage, not your own code.
wrap my Web Service within a Remote API which I have yet to experiment with.
Based on my current understanding, it seems there is no way for a Google Account authenticated custom written Web Service to be accessed by a non-human user. Is this correct?
Since you are interested in interacting with RESTful web-services programmatically (without human intervention), we are essentially talking about securing a REST API.
There is a plethora of resources on this matter throughout the internet but the gist of it is:
you should use SSL and sessions or OAuth to secure your endpoints.
Depending on how far you are in the current project, you could consider making use of Cloud Endpoints, there you'll have the option to use OAuth2 (and have DDoS protection), as well.
Hope this helps.
I managed to get this to work in the end by:
Switching off the web.xml security-constraint so that the API doesn't redirect to Google Login.
Modifying my API to take in a Oauth2 token in the Authorization header instead.
Validating the token based on the code sample here: https://github.com/googleplus/gplus-verifytoken-java
I didn't go with Cloud Endpoints, but Jersey + Dropwizard components instead. Dropwizard has built in Oauth2Provider which I simply implemented a Authenticator class and it works.
I need to use Active Directory Federation Services (ADFS) authentication in a Django application. I will create an authentication backend, but which tool would someone recommend me to make it as fast as possible, or would it be better to implement authentication from scratch?
I have read some articles from the Microsoft website, and have checked:
http://claimsid.codeplex.com/
http://msdn.microsoft.com/en-us/library/ff359102.aspx
But even though they explain some core concepts and ideas about ADFS and SSO, the examples are in my opinion more .NET stack focused.
Writing a basic client in .NET and sniffing the traffic would give you all necessary clues to actually implement the flow in any technology.
Basically, your django app has an endpoint adfs uses to return back. You register the endpoint in adfs (like https://myapp.com/authgateway).
Then, your application initializes the flow by redirecting to https://adfs.address/adfs/ls?wa=wsignin1.0&wtrealm=https://myapp.com/authgateway
Adfs picks the request and validates credentials. Then it creates a SAML token and redirects back to your application with a POST request containing the token.
Then comes the difficult part, the SAML token is a plain xml you can use to establish a local user session. One of the claims contains user name provided by adfs, other claims can contain roles, the email, whatever you configure at the adfs side.
But, to prevent forging, you need to validate the token. The validation consist in checking the XMLdsig signature and verifying that the signing certificate thumbprint matches the thumbprint of the adfs signing certificate. Depending on how much knowledge on x509 certificates and xml validation you have this can be easy or difficult. Try to find any support in django community.
Anyway, as you can see the basic flow is simple, is a matter of two redirects, a 302 from your application to adfs and a POST back from adfs to your application. Although we do this daily in .net, our partners do it in php/java under our guidance.
There's a package available for this here:
http://django-auth-adfs.readthedocs.org/en/latest/