I use ngrok to test my flask app with OKTA. For which my ngrok public URL gets changed time to time. I need to change my OKTA application integration setting based on the current URL as given below
Single Sign On URL http://4e4f-103-97-210-83.ngrok.io/saml/sso/example-okta-com
Recipient URL http://4e4f-103-97-210-83.ngrok.io/saml/sso/example-okta-com
Destination URL http://4e4f-103-97-210-83.ngrok.io/saml/sso/example-okta-comAudience
Restriction http://4e4f-103-97-210-83.ngrok.io/saml/sso/example-okta-com
it is very tedious jobs to change URL everywhere when there is only change in string "4e4f-103-97-210-83"
is there any macro facility to define in OKTA app integration something like below
# url_part 4e4f-103-97-210-83
http://${url_part}.ngrok.io/saml/sso/example-okta-com
I just need to change url_part macro based on ngrok output, and it is good to go.
Any idea?
You can use Okta API to make this change for your app config, or Terraform which uses the same under the hood.
Or you can get a plan from ngrok, which allows to keep public URL permanent
Related
I have a single ASP.NET MVC app - website and API controllers. I'd like to use Azure API Management to manage these APIs but retain the same URL so that it is seamless for our consumers. We have a custom domain setup on the app service for this web app that is currently used to serve up both the site and APIs(e.g. Website: xyz.com, APIs: xyz.com/api1, xyz.com/api2, etc.). Also we use AAD for auth. and have the redirect URI setup to the custom domain(xyz.com). Everything works great at present.
The issue arises after we configure API Management to expose our APIs and potentially use it as a passthrough. In order to ensure that the URLs remain the same after API Management is introduced we set the custom domain to be on the API Management instance itself and removed it from the app. service. This is how our current setup looks -->
User hits xyz.com and the request proceeds as follows -> Traffic Manager -> APIM(xyz.com) -> App Service(xxx.azurewebsites.net)
After that last point above, AAD auth. should kick in and once it has the access token after successful auth. it should redirect the user and the page should load. But it doesn't. Instead we get a blank page and if we refresh it, then and only then does it proceed to auth. and load the page.
We have tried setting our redirect URI to both the custom domain(xyz.com) as well as the base app service name that Azure generated(xxx.azurewebsites.net).
Directly hitting the API urls specifically(e.g. xyz.com/api1) works fine. It goes through APIM and responds as expected. The only problem is that the website doesn't load as outlined above.
The moment we take APIM out of the equation, and set the custom domain back on the app service again, everything works as expected.
I'm trying to figure out if we've misconfigured our assets for this scenario somehow or if APIM doesn't support pass through for the website in this manner. Any thoughts/suggestions here would be much appreciated!
Wow, that was a lot of text.
Ok, let's see:
Visitors -> Traffic manager -> APIM -> backend (your website) - ok got it.
this is like a common way of using APIM, and it should work. However, maybe your policies are not set up correctly?
Have you built your product/API/Operations? Do you see requests coming from APIM hitting your site? What responses are you getting?
Now, of course, you will need to define and set up APIM (products, APIs, and every operation) to pass it throw to your backend. This means if you (as a visitor) need to list all products, you would need to go through the APIM operation (sed GetProducts ). Your request will be passed through the Inbound policy(adjust and build the request if needed), pass it to the backend( to your website with custom APIs), and the response will be sent back from the backend back to the visitor.
Now to this: to protect your Web API Backend in APIM, you could use OAuth 2.0 authorization with Azure AD:
big picture overview:
Register an application (for your backend) in Azure AD to represent the API
Register another Application (the client) in Azure AD to represent a client app that will call your API
And I guess this is the one for you grant permissions to allow the client app to call the backend app
And, of course, add the validate-jwt policy to validate the OAuth token for every incoming request
Read om on this here https://learn.microsoft.com/en-us/azure/api-management/api-management-howto-protect-backend-with-aad
I am trying to use the Docusign API for my development.
But here is one issue with the authentication API .. it needs a Redirect URL.
Because I need to use this API in the Rest API tool and in AJAX call. so it is not possible to provide the Redirect URL .
Can't we call this API without Redirect URL in AJAX or in REST API tool.
This is part of the rule of OAuth 2.0
The redirectUrl is used to actually redirect the user somewhere after they authenticate.
But it is also used to ensure that the clientId (integration key) was used by the right app to go to a valid URL that was registered with them. This is to protect from potential phishing.
So, yes, you need to have one, and you need to ensure it's registered for your integration key.
If your app is a single page application then you should use OAuth Implicit grant.
If your app is a thick client app, then Implicit grant is also used. In this case, it is common to use a private scheme such as larrysApp://app/redirect as the redirect url and register the scheme with the OS so your app will receive the URL.
Also, please be sure to NOT use the authentication category of API methods in the DocuSign eSignature API. They're obsolete. Instead, use OAuth, as documented on the DevCenter
I'm running through cooking up my own test IdentityServer, but I'm hitting a snag. The ClientUri and RedirectUris must be specified for every browser based client. I know these can be stored in the DB, but is there any way to insert wildcards here?
Each of our customers receive their own subdomain and I would like to simplify user management by allowing all browsers attempting to access any of our apps at *.ourcompany.com to be treated as the same client in the identity server. Is this possible.
You can implement your own redirect URI validator. But for security reasons, this is not recommended as it expands the attack surface.
Redirect Uri Validator Interface
How to register your custom validator
Discussion about redirect uri
Identity Server4
I think you can add AddCustomAuthorizeRequestValidator in the startup. Still, it is not recommended to modify the redirect URI validation.
Add Custom services
Related Discussion
For IdentityServer4, you can implement your own IRedirectUriValidator and register it using the AddRedirectUriValidator extension method in Startup.cs.
services.AddIdentityServer(options =>
{
// ...
})
.AddRedirectUriValidator<CustomRedirectUriValidator>();
By default, the StrictRedirectUriValidator is registered but can be overridden by calling .AddRedirectUriValidator as shown above.
I'm trying to use stormpath within my heroku application but I'm confused about the purpose of the STORMPATH_URL environment variable exposed to my application.
This variable holds the URL to my Stormpath Application, not to stormpath server URL. So if I used the value of this environment variable to set the base URL to the stormpath server, my calls won't work and fire a 404 exception
HTTP 404, Stormpath 404 (mailto:support#stormpath.com), RequestId xxxxx-xxxx-xxxx-xxx The requested resource does not exist.
But if I leave the client's base URL empty to use the default Stormpath server URL, everything working fine. So what is the purpose of having this environment varibale exposed to my application?
I can see that this URL points to my Stormpath Application, so why do I need it since I can already get my Stormpath Application using it's name?
The purpose of the STORMPATH_URL environment variable (or STORMPATH_APPLICATION_HREF, same thing) is to tell your Heroku application which Stormpath Application resource it should be "associated" with. A Stormpath Application represents your real-world app that has users, roles, and so on. When your Heroku dyno spins up, it needs to know which Application resource it should use to authenticate users, etc.
You're right that you could just look up your Stormpath Application by name, instead of href, but looking up via href is faster. :)
You normally don't have to touch this variable. If you have your Heroku application pointed at the correct Application resource URL in your Stormpath backend, it should just work!
I am having an issue with trying to create a bot. Everything seems to work fine when I am using Http. I can deploy my application to my website and interact with the bot via the emulator or botframework.com.
Unfortunately, when I try to use HTTPS, I get a 401 error from the emulator and nothing shows up when I try to use botframework.com.
Just so that I am crystal clear, the only things that I changed are:
1. Added the [BotAuthentication] attribute to my ApiController like so:
[BotAuthentication]
public class MessagesController : ApiController
Updated the URL in the emulator/botframework.com from http://mywebsite.com/api/messages to https://mywebsite.com/api/messages
Web.config is all set up with the appId and AppSecret. My site already has an SSL certificate.
Is there anything that I am missing? Although I have never used basic authentication before I am assuming there is nothing else that I need to set up, right?
I hit your endpoing and IIS is responding to the basic auth and getting in the way.
Basic Auth is works the following way:
There is a header which contains the UserId:Password encoded as base64
If the server doesn’t see the header it returns a 403 with a “basic” to signal that the web site requires auth token. For a web browser that means it will popup a stock user/password dialog and then it will do submit the request again with the header.
If the header is provided but the user/password is wrong the server returns 401.
Normally basic auth is used to look up in a database, but in our case there is only 1 user, it is the bot appid/appsecret. All the BotAuthorization attribute does is to add an inspector to the request pipeline to look for the header with appid/appsecret in it to make sure that only approved callers can call your bot.
If you don’t care about that you can simply remove the attribute. Regardless, you don’t want IIS sticking it’s nose into the process.
Make sense?
This theoretically should work based on your description of the changes you've made. This is the emulator talking to your cloud service or to the bot on localhost? And you get this error as well from the Bot Framework test control in the portal?
If you send me your BotId to botframework#microsoft.com I can check our logs to see if there's anything interesting (or DM me at #jameslew on twitter).