I have an IdentityServer 4 setup using SaasKit to support multi-tenant URL paths. This allows me to access the single IS4 instance in a multi-tenant way like so:
https://localhost:5000/tenant/tenant1/.well-known/openid-configuration
The IS4 instance uses a single database for client/scope configuration rather than one per tenant. Only the users database is separated per tenant.
My issue is that a client only ever has one configuration and so has one RedirectUri and PostLogoutRedirectUri, and these values must be tenant specific URL paths otherwise the callback won't be handled in the context of a tenant in the client app.
So, I can specify in my client app's tenant-specific OpenIdConnectOptions new values for CallbackPath, SignedOutCallbackPath and RemoteSignOutPath, e.g. like this:
options.CallbackPath = $"/tenant/{tenant}{options.CallbackPath}";
but obviously this requires the relevant tenant fragment to be included in the client's config RedirectUri property otherwise IS4 will invalidate the redirect uri.
Whilst I could use dynamic clientIds from the client app, I'd prefer not to create a tenant-specific client config in IS4 for each tenant, and deal with the management issues. Likewise, I'd prefer not to add all possible tenant-specific redirect URIs to the single client's config.
Instead, is it possible to implement and register with IS4 some custom components that supports the following functionality, and if so which interfaces should I implement?
A parameterized redirect URI path so the following can be specified:
https://localhost:5000/tenant/{tenant}/signin-oidc
Resolving a parameterized URI path into a real path when redirection is required.
You can implement a custom redirect URI validator.
For that, you need to create a class that implements IRedirectUriValidator and then register it like this:
services
.AddIdentityServer(...)
.AddRedirectUriValidator<MyCustomUriValidator>();
This way you can set the redirect URI for the client in the database using some notation to specify the tenant-dependent part of the URI and then check it at runtime with the custom validator.
Beware of the dangers associated with dynamic redirect URIs.
Related
I am building a multi tenant application. We are not using Azure Active directory.
We are using logic apps as a back-end services. Since each and every API url has a parameter tenant, we wanted to include at the API management level.
https://apm-eso-01.azure-api.net/{tenant}/v1/{siteid}/inventoryItems
Is there any possibility to add path parameter to the host URL at the API Management level rather than including at the logic app as a relative path.
Backend Urls. We have different instnaces/servers for each tenants
Tenant1 :
https://esous-devpd1.host.com/retail/data/esosm/api/v1-beta2/get/1
Tenant2:
https://esospanish-devpd1.host.com/retail/data/esosm/api/v1-beta2/get/1
APIM Urls
https://apm-eso-host-sbx-01.azure-api.net/lse/{tenant}/ esosm/api/v1/get/1
In-order to support the place holder for tenant at the APIM url/endpoints, I should add tenant place holder or path parameter to the backend url as below.
https://esous-devpd1.host.com/retail/data/esosm/{tennant}/api/v1-beta2/get/1
But all my urls should have tenant as a path parameter.
So my question is can we add tenant place holder or path parameter to the APIM end point and just rewrite the backend server url as such to include the tenant parameter rather than adding it to the backend url
This can be achieved by making sure that all operation URL templates in APIM start with /{tenant}/. Then you can add a policy at global or API level to make the transformation:
<rewrite-uri template="#{
var operationPath = context.Operation.UrlTemplate.TrimStart('/').Replace("{*", "{");
var result = operationPath.Substring(operationPath.IndexOf('/'));
return ("/retail/data" + result).Replace("/v1/", "/v1-beta2/");
}" />
This policy will rewrite URI of current request by removing first segment from URI template. So if APIM receives request to /{tenant}/xxx operation it will rewrite it to /xxx.
And then you can add tenant as a query parameter by:
<set-query-parameter name="tenant" exists-action="override">
<value>#(context.Request.MatchedParameters["tenant"])</value>
</set-query-parameter>
My front end is using ReactJS and when I was testing locally I was using axios to make the calls. e.g.
axios.defaults.baseURL = process.env.REACT_APP_API_URL;
axios.get('/me').then((resp) => {
this.setState({identity: resp.data});
}).catch(() => {
console.log('Failed to retrieve identity');
});
I have now moved my API behind Azure API Management which is set up to require a subscription to use.
Part of the APIM policy checks the Active Directory group to validate the user is in the right group.
Therefore, I need to add 2 parts to my javascript
authenticate against Active Directory
send the Ocp-Apim-Subscription-Key in the header
react-adal looks like it might handle the login.
However, I can't work out how to modify my existing code to use it and send the header.
Its also not clear whether it is a security risk to hard code the Ocp-Apim-Subscription-Key in the javascript or if it should be retrieved on the fly.
If it should be retrieved on the fly, where should I store it and how should I retrieve it securely?
After you handle the login with react-adal, you can also modify how you send the subscription key to APIM.
APIM lets you define how you want to send the subscription key - custom HTTP header or the query string:
Both fields are text fields with pre-defined values which you can freely change (well keep in mind these are either HTTP header name or query string variable names).
To the question weather you should keep that secret. Well, you subscription key is your secret. And it is not short lived like the access token. So you should keep that as secret as possible and do not just put it in your JS code.
However I am not really convinced that a SPA application should use APIM subscription key to invoke the API. APIM subscription keys are just a symmetric keys used to authentication/authorization. As such (being symmetric keys) using these in a SPA application be would like using your username and password for the database in your SPA app. It doesn't really matter in what stage you put that key in the browser. The moment you put APIM subscription key in the browser, you cannot longer trust that key. Users can modify it, completely remove it, or use another valid subscription key if they find one.
For SPA application I would just use the Azure AD Authentication and shape the authorizations based on the bearer token. I suppose you already perform JWT validation checks in your policy? You can extract any and all claims form the token and you can make authorization decisions based on claim values.
If the React app is hosted in Azure App Service, then you should be able to register the React app with managed identity and use Azure KeyVault to keep the secret.
https://learn.microsoft.com/en-us/azure/key-vault/tutorial-net-create-vault-azure-web-app
The authentication process for O365 requires adding the redirect URL in a whitelist on the app’s dashboard on Azure.
However, this whitelist doesn't work with domain names. It requires to add the entire URL for every page which is not possible if you have a huge number of URLs, plus some of the URLs are dynamically generated by the backend.
Is it possible to whitelist the domain with all its sub-directories/URLs in one go?
No, it is not (unless you want to use wildcards, which you shouldn't).
In general when you need dynamic redirects,
you should store the location you want to redirect to locally in a cookie/session/local storage/session storage.
Then use a single redirect URL, and when you get the redirect there, get that stored "local redirect URL" from where you stored it, and redirect the user there.
I touched upon this on a recent article: https://joonasw.net/view/avoiding-wildcard-reply-urls-with-msal-js
I'm in the process of implementing AAD single sign on in our application and we will be using the adal.js/adal-angular.js library with our MEAN stack application. Part of initializing the library is to call init() and provide the tenant and clientId
adalProvider.init(
{
tenant: "mycompany.onmicrosoft.com",
clientId: "05bdd8d7-XXXX-XXXX-XXXX-5f2769f8b9b6"
},
$httpProvider
);
for example.
If someone views the source and takes the tenant and clientId can they use that somehow in their own application maliciously?
Does AzureAD check the URL the request came from and block it if it's not the configured login url?
Seems as though the clientId is more like a public key but if the only 2 things needed for an app to trigger authentication with AzureAD is the tenant and clientId and those are exposed client side in source code that someone could use them to create a phishing site X or to grab id_tokens if the request is redirected back to their site X rather than the original site
Does Azure rely on the configured settings in the application setup and protect against this?
I'm still getting a grasp on the OpenID Connect and OAUTH 2.0 finer points so forgive me if this question has an obvious answer.
Adal.js uses the Implicit flow (as per OpenID connect / oAuth 2 specifications) and exposing the ClientID (and tenant id of AAD) doesn't pose any security risk.
While registering the Clients in Azure AD administration panel, we specify a Redirect URI for the client. This is the Application URL for which users will get redirected after successful authentication.
So even if a malicious client tries to use your clientid and tenant id, the users will be redirected back to the registered URI(which is your app) after authentication and not to the malicious site
In implicit flow the application doesn't collect any username / password, IDP/OP (i.e AAD) manages this part - so user credentials won't be compromised as well
**For other flow types (Authorization code, Client credentials,etc) we have something called client-password along with ClientID. This shouldn't be exposed to public clients.
I am currently working on a small project using RESTlet on Google App Engine/Java.
I was searching.. searching.. and couldn't find the exact or understandable solutions for my doubts.
My question is that How am I suppose to implement my own SignIn & SignUp module without using google's UserService or Spring Security??
Is there any actual sample code available??
I mean SignUp part is just a simple JDO insert & select module. let's just say I've done it.
How am I supposed to handle each user's request session and authentication??
I am thinking about using HTTPS on every request.
Any suggestions or help would be really appreciated!
Thanks in advance.
In Restlet, you have security support on both client and server sides. On client side, you can specify security hints using the ChallengeResponse entity. This feature is open and you can specify the authentication type you want. In the following code, I use an http basic authentication based on username / password:
ClientResource cr = new ClientResource(uri);
ChallengeScheme scheme = ChallengeScheme.HTTP_BASIC;
ChallengeResponse authentication = new ChallengeResponse(
scheme, "username", "password");
cr.setChallengeResponse(authentication);
Restlet will automatically build necessary headers in the corresponding request. You can note that Restlet supports a wide range of authentication types through its extensions. I know that some work is done at the moment to support OAuth v2 (see http://wiki.restlet.org/developers/172-restlet/257-restlet/310-restlet.html).
On the server side, you need to secure accesses at routing level using the ChallengeAuthenticator entity, as described below. This can be done within your Restlet application:
public Restlet createInboundRoot() {
Router router = new Router(getContext());
ChallengeAuthenticator guard = new ChallengeAuthenticator(getContext(),
ChallengeScheme.HTTP_BASIC, "realm");
guard.setVerifier(verifier);
guard.setEnroler(enroler);
guard.setNext(router);
return guard;
}
Like for client side, this support is generic and is based on two interfaces that need to be specified on the guard:
The verifier one to check if authentication is successful
The enroler one to fill roles for the authenticated user
You can notice that same security technologies need to be use on both sides...
If you want to manage authentication session for user, you need to implement it by yourself using cookies.
When authentication successes on server side, you can return a cookie containing a security token that allows you checking the user from your database (for example). Some code like below can implement that:
CookieSetting cookie = new CookieSetting(0,
SECURITY_COOKIE_NAME, securityToken);
Series<CookieSetting> cookieSettings = response.getCookieSettings();
cookieSettings.clear();
cookieSettings.add(cookie);
You can extend for example the SecretVerifier class of Restlet to add a test on security data received and add this code when receiving the security cookie.
On client side, you need to add hints for authentication the first time and then re send the security cookie following times, as described below:
ClientResource clientResource = (...)
(...)
Cookie securityCookie = new Cookie(0,
SECURITY_COOKIE_NAME, securityToken);
clientResource.getRequest().getCookies().clear();
clientResource.getRequest().getCookies().add(securityCookie);
Hope it will help you!
Thierry
If you are interested in re-using social accounts, you need to integrate with each one like facebook oauth
And/Or use the app engine authentication via OpenID
Both ways define an API to authenticate a client, you can use the UserService or manage your own state via cookies.