Some networks are configured so that trusted clients and resource providers access IdP via back-channel URL (e.g. http://idp.mycorp.local), while public clients like SPAs access it via front-channel URL (e.g. https://idp.mycorp.com).
Which is the ideal solution for such a network configuration?
We have been experiencing with the following options:
Populate some endpoints (authorization_endpoint, end_session_endpoint) in the discovery document with the front-channel host name regardless of which host name was used for requesting the document;
Configure trusted clients to access IdP via back-channel URL, but switch to using the front-channel URL when it is going to redirect the user agent to IdP.
Related
I have been tasked with integrating Azure Active Directory Authorization into one of our applications and have tried out some of the samples with relative success.
I have a Javascript SPA application (GoogleWebToolkit) that communicates with a Spring REST (not Boot) API. The Rest API is currently secured with Spring Security and login URL username/password etc.
I want to change this to use Azure OAuth2.
Being new to OAuth2 I'm trying to figure out if I should be using either of the following Spring options.
With this option all the configuration is done at the server side, client id,secret
If I do a href from the SPA front end to 'oauth2/authorization/AzureAD' URL, its sends a redirect to the Azure Login page, allows authentication and redirects back to what redirect URL I enter into the Azure AD console configuration. This works to a degree but trying to extract the token and pass it back is not working so far.
http.oauth2Login()
.clientRegistrationRepository(clientRegistrationRepository())
.authorizedClientService(authorizedClientService())
.authorizationEndpoint()
.authorizationRequestResolver(
new CustomAuthorizationRequestResolver(
clientRegistrationRepository(),
#Bean
public ClientRegistration clientRegistration() {
ClientRegistration.Builder builder = ClientRegistration.withRegistrationId("AzureAD");
builder.clientAuthenticationMethod(ClientAuthenticationMethod.CLIENT_SECRET_POST);
builder.authorizationGrantType(AuthorizationGrantType.AUTHORIZATION_CODE);
........................
or
I haven't fully tried this option yet, but I think it involves doing the authorization directly from the SPA javascript front end, put all the values for the client id/secret into the javascript FE etc, and then passing the once acquired token via the Auth header for validation by the server side. Like at https://www.baeldung.com/spring-security-oauth-jwt
.oauth2ResourceServer()
.jwt()
.jwkSetUri("https://login.microsoftonline.com/common/discovery/v2.0/keys");
Could someone confirm where I should be using Option 1 or 2, and if I am understanding things properly?
Your understanding is correct in option 2. As per above scenario, let’s consider Front End Application which is Single Page Application (Java Script) to be OAuth Client App to orchestrate the process of obtaining access token and then grant access to resources from Spring back-end application.
So, here client Application need to be registered in Azure AD to acquire the access token secured by Azure AD.
We recommended MSAL libraries which helps to acquire tokens from the Microsoft identity platform and handle token in many ways to authenticate users and access secured web APIs.
Both the applications (front end and back end) need to register in Azure AD based on the scenario.
Update client-id, tenant-id, redirect URI to front end application configuration file based on application registration in Azure AD.
Back-end application also need to be registered in Azure Ad to secure by Microsoft Identity which can then define the delegated permissions(scopes) your API exposes.
Then business logic needs to add in back-end application to determine what is allowed or prohibited based on these scopes in access token.
To authorize the client request in Spring application:
Users will start by authenticating with a username and password in front end application.
Once authenticated, the client will receive a JWT representing an access token.
The client will include the access token in the authorization header of every request to a secure endpoint.
The resource server will validate the access token and determine if it has the right permissions, using the information within the token.
In this case, Spring serves as resource server and not acquiring any token in the back-end application .
Security Configuration in Spring provides numerous methods to add filters to the HTTP request to authenticate each request.
Here,
http.cors() will allows Cross-Origin Resource Sharing (CORS) checks to succeed.
All the requests need to authenticate before passing to the application(controllers).
Spring application serve as a resource server and authentication should be provided via JWT access tokens and further validate the roles and scopes in the application’s controller using #AllowedRoles annotation.
Our JWT access tokens are signed by Azure AD and application should check if their signature is correct. Azure AD has an endpoint with the public key to do so, which need to configure in spring application.
Also, as mentioned, we will need access token to call the protected back-end application because contents of the token are intended for the resource (back-end API) to perform authentication and authorization.
To validate the token, you can search the keys endpoint in the discovery document and then provide this JSON web key (JWK) endpoint straight away where JWK URI can be found.
# application.properties
spring.security.oauth2.resourceserver.jwt.jwk-set-uri=https://login.windows.net/common/discovery/keys
Note: The flow would be same to get the access token while integrating with Azure AD. i.e in Spring boot or in spring.
As part of our Azure AD and HashiCorp Vault OIDC single sign-on implementation, I have registered an application in our corporate Azure AD and provided a couple of allowed redirect URIs in my Terraform configuration that are along the lines of the following:
allowed_redirect_uris="http://localhost:8250/oidc/callback"
allowed_redirect_uris="https://{hostname.domain}:8200/ui/vault/auth/oidc/oidc/callback"
The terraform configuration is provisioned via a GitLab CI/CD pipeline and manages to deploy successfully. However, when I then attempt to login into Vault via the UI (as shown below), I get a Microsoft Sign in error message pop-up which includes the following:
AADSTS50011: The redirect URI 'https://{hostname.domain}/ui/vault/auth/oidc/oidc/callback specified in the request does not match the redirect URIs configured for the application '{Azure Tenant Id}'. Make sure the redirect..............
Note: The URL displayed in the error message is somehow missing the port number 8200 which is definitely included in our Azure AD registered app redirect uri configuration.
I have even tried stripping out this same port number from my Terraform code and redeployed, all in an attempt to keep it consistent with the expected URI given in the error message. Yet still, this has failed to yield the desired result and I keep getting the same error.
Any idea what could be the issue?
Found one of the similar issue , please check if that could help .
According to discussion in similar github hashicorp vault issues
Vault’s OIDC provider should validate loopback IP redirect URIs
according to rfc8252 section-7.3 : The authorization server MUST
allow any port to be specified at the time of the request for loopback
IP redirect URIs, to accommodate clients that obtain an available
ephemeral port from the operating system at the time of the request.
This Feat/OIDC loopback redirect dynamic by paladin-devops hashicorp/vault · GitHub
discusses to add checks on OIDC provider to allow for redirect URI to have a dynamic port in the redirect URI if the loopback address is included in the OIDC client
References:
OIDC Provider Loopback Interface Redirection Issue- hashicorp vault (github)
hashicorp vault/OIDC loopback redirect dynamic by paladin-devops
GitHub
I'm trying to use AWS Cognito with a user pool using Azure AD as an Identity Provider (OpenID Connect).
I set up the User Pool in Cognito and specify the callback URL of my test app (https://localhost:44381) and I configure an App Registration in Azure AD that has the same URL in the Redirect URIs.
In the AWS Console, under App Client Settings, I click "Launch Hosted UI" to test it. It displays a page that lets me choose my configured Identity Provider (Azure AD). On that page, I can see in the URL what it has for "&redirect_uri=". It has https://mydomain.auth.us-east-2.amazaoncognito.com/oauth2/.
So I put that URL in both AWS Cognito and in Azure AD as the Callback URI/Redirect URI.
Then when I click through to the Identity Provider, it pops up the normal Azure AD login and lets me log in, but I get:
AADSTS50011: The reply URL specified in the request does not match the reply URLs configured for the application: '60e47fff-e2cc-41d8-8405-283bafb33fbb'.
This is the application (client) ID from Azure AD.
Likewise, when I run this from my test app, I can see the redirect_uri=https://localhost:44381/oidc in the URL - but same thing happens - redirect mismatch. Though that exact URL is in both AWS and Azure AD.
How can I find out what it is trying to "match"? It's obviously changing something in the URL that I give it.
I'm implementing a Power BI Embedding solution into third party application which uses the same Active Directory as Power BI. However the application has URL with HTTP and not HTTPS.
Now, for getting the authentication token for embedding, I've created Azure AD Web App and I want to add Redirect URI for that application, but it is not allowing me because it is HTTP.
What can be the solution to get authentication token for Azure AD for embedding?
Thank you.
Apps that are registered for Microsoft identity platform has Restrictions on redirect URLs. The redirect URL for web apps and
services must begin with the scheme https, and all redirect URL values must share a single DNS domain. http://localhost is also supported as a redirect URL.
You can create self signed certificates for https domain (for test purpose).If your app runs in Production Environment, it should be signed by a
trusted certificate authority.Check here to know more.
Refer this post for : Trust a self signed cert from IIS
Since it is mandatory to register non app-engine endpoints as mentioned here,I can't register my endpoint and it shows the error: Invalid property URL; please specify a site or directory URL, not a page URL.Screenshot here
What can be the alternative?
Make sure you have:
A HTTPS server.
A valid SSL certificate.
Register the endpoint domain with the GCP project.
Register the https:// version of your site URL.
Configuring HTTP Endpoints
You need a publicly accessible HTTPS server to handle POST requests in order to receive push messages. The server must present a valid SSL certificate signed by a certificate authority and routable by DNS. You also need to validate that you own the domain (or have equivalent access to the endpoint). Finally, you must register the endpoint domain with the GCP project. Note that these steps are considerably simplified on App Engine, where SSL certificates are provided and verification requirements can be relaxed.
Step 1: Verify you have access to the domain
Complete the site verification process using Search Console. Be sure to register the https:// version of your site URL. For more details, see the site verification help documentation.