I found this article that describes configuring to use the AWS VPN Client.
https://aws.amazon.com/blogs/networking-and-content-delivery/authenticate-aws-client-vpn-users-with-saml/
Our team is currently configured using the OpenVPN Client and we would like to keep using it -- (OpenVPN Client is so much better)
The issue seems to be where we Add the Application to OKTA. Our OKTA guy tells me there is no option to add OpenVPN as a client and that there is no "OIN template" to allow this.
Is there a solution to this problem ?
I have functioning AWS Client VPN that authenticates with Okta.
I contacted AWS support and was told that SAML/Okta authentication only works with the AWS provided client.
Related
I have created a tenant and application to be able to authenticate users via Azure B2C. I have a front-end application in React which uses Msal.js with authorization grant to obtain the access token, which is then used to make requests to a webserver which acts as a resource-server (connected to Azure b2c as well). I have used this answer to make it work -> How to secure Spring Boot REST API with Azure AD B2C?
Apart from that I have few daemon applications which need to connect to the backend as well. They should use client_crendentials grant_type to connect to the backend server (which is a resource-server).
However, the token that is obtain by the daemon app, cannot be used with the backend server (resource server) for some reason. Is there something that I do wrong ? Do you have samples for this scenario ? I've already spent days looking over all the documentation to find where is the problem.
Microsoft will end support for basic authentication in Exchange Online remote powershell October 13th, 2020.
Server-to-server communication can be done using the System.Management.Automation.Runspaces.WSManConnectionInfo class with basic authentication. What is the supported way for an on-premise daemon application to run remote powershell in Exchange Online when basic authentication is no longer supported?
If you don't want to rewrite your remote PowerShell code to use the new V2 Exchange Online Management module shown by #stukey above, you can use an alternative workaround by using ADAL (or a similar library) to fetch an access token from AzureAD, then use the token as password when constructing your PSCredential.
If you add ?BasicAuthToOAuthConversion=true to the connection URI, the server will then pull the token from the basic auth header and use modern authentication with the token instead.
The workaround is outlined here and semi-documented by Microsoft here.
Assuming your daemon application is using a Service Account ID without MFA, then you can utilise the new V2 Exchange Online Management PowerShell module to connect to EXO using Modern Auth. It handles everything for you, so you can still initiate a connection using your Service Account username and password credentials, and the module will use those creds to get a token from Azure AD and then authenticate to EXO using Modern Auth. Works great if your Service Account creds are managed by a separate password vault solution. If you can’t use credentials-based auth, then Microsoft are working on an update to the EXO module that will allow you to authenticate to EXO using a registered Azure AD app together with certificate-based auth. That should be coming soon...
I am new to OpenID connect & security domain. I have configured Nifi to use OpenID for authentication using online documentation. And to automate a few nifi related tasks we are using nipyapi.
I have already written python code which does automated flow deployment for basic nifi installation (unsecured & without user authentication)
Now, I have to move the code to secured Nifi installation. How to authenticate to OpenID connect using nipyapi/rest API ?
AS per discussion with Bryan, i am planning to use client certificate for authentication but it started giving authorization error. and have created another question with the details.
Nifi - Client Certificate Authorization Error
OpenID Connect generally requires that you follow a flow of re-directs, typically in the browser. NiFi re-directs you to the login page of the OIDC provider, upon completion, the OIDC provider redirects you back to NiFi. I'm not exactly sure how, or if you even can, perform this login process from scripts. An easy alternative would be to just generate a client certificate to represent an automation user for any NiPyApi scripts. Client certificate authentication is always enabled by default for NiFi.
I have configured composer-rest-server. I had also provided fabric username/password while configuring composer-rest-server (WebAppAdmin or admin). Now, I can able to access REST API without providing any credentials (through postman or loopback).
I would like to understand how we can secure composer-rest-server. Though, I have understood that we can add participant and issue identity, but not able to connect logical dots in context of how everything will work.
How to secure composer-rest-server while accessing REST API?
When and How we are going to use "username/secret" registered against any participant?
When to authenticate composer-rest-server API and When to use participant identity to access business network?
Please see the documentation on this subject:
https://hyperledger.github.io/composer/integrating/enabling-rest-authentication.html
My mobile app needs to make secure API calls to on-premise backend services which is not exposed to internet but accessed only by mobile client. How can we secure the backend calls via AWS cloud?
Thanks in Advance
AWS does not have an out-of-the-box solution for what you are looking for. Amazon Cognito's Identity component was designed to secure access to AWS API's, not a developer's. You will have to build your authentication and authorization service for your mobile clients.
Another AWS technology that you may want to consider in your design is Amazon Virtual Private Cloud (VPC), which would allow you to bridge your on-premise network into the AWS cloud. From their you would have to properly secure systems and APIs.
Update 2015-07-09 AWS has announced Amazon API Gateway. Using API Gateway you can build a REST interface to your existing API (or to AWS Lamdba functions) secured with credentials retrieved via an Amazon Cognito authflow. See this blog post for additional announcement details.