I'm trying different ways of implement multi tenant AppEngine web RESTful interface.
One of them is to use part of the URL as the tenant name.
The problem is that I'm using Jersey as JAX-RS implementation for RESTful interface and I would like a url such as /tenant1/res1 to first be parsed by something that will take the /tenant1 part, set the namespace to tenant1 and then pass the rest of the URL to Jerseys' servlet for regular handling.
The something maybe either ServletFilter or Servlet or something I can't think of.
How can I implement such thing?
What are the possible problems of such implementation?
Thank you,
Ido.
I do exactly that but using Restlet. The namespace uniquely identifies the customer that a user belongs to.
The first URL fragment contains the namespace. I verify the namespace in a RESTLET authenticator (basically a filter) and when the authenticated user does not belong to the given namespace/customer I refuse to proceed.
I use the primary key of the customer as the namespace. This has the added advantage that a valid namespace/customer can be easily (mem-)cached, and I refuse any calls containing invalid namespaces.
Very happy with this setup and no problems encountered.
Related
Currently we have an application in production that allows for Single sign-on in tabs, we followed https://learn.microsoft.com/en-us/microsoftteams/platform/tabs/how-to/authentication/auth-aad-sso and this works well.
For this to work an Application ID URI is set, like so: api://www.domainusedintab.com/378271d1-b8e4-4f01-a9bb-e724dbec43c8, where 378271d1-b8e4-4f01-a9bb-e724dbec43c8 is some application ID.
We now want to add Single sign-on support for bots, like described in https://learn.microsoft.com/en-us/microsoftteams/platform/bots/how-to/authentication/auth-aad-sso-bots. To make this work a change is needed to the Application ID URI, api://botid-5d417275-b104-462e-9998-2b2b0ec4244f, where 5d417275-b104-462e-9998-2b2b0ec4244f is the ID of the bot service.
The problem is that it's not clear on how to combines these two into a single Application ID URI, based on the previous documentation pages it seems it's one way or the other.
We tried to just tack on /botid-5d417275-b104-462e-9998-2b2b0ec4244f after our current Application ID URI, to make api://www.domainusedintab.com/378271d1-b8e4-4f01-a9bb-e724dbec43c8/botid-5d417275-b104-462e-9998-2b2b0ec4244f. This seems to work fine... But it also seems like a bit of a hack that might break at any time.
Are there any resources on how to properly solve this?
We can add the existing bots to the existing application to work on SSO. We need to add the web applcation info in the manifest to view the changes in the application. For more information please check Single sign-on (SSO) support for bots
As it turns out, it is possible to provide multiple Application ID URIs for an App registration. This is not available through the Expose an API interface, you need to change it directly in the manifest. The identifierUris field holds the Application ID URIs — the current one from the Expose an API interface should be the only item here.
We have implemented IdSrv4 on top of AspNetCore Identity and we use ADFS as external IdP. From ADFS we wan´t to get the users AD-groups, upn and som other claims. The claims will be used both inside our IdSrv4 implementation, but will also be sent to our API-resources as part of the access token.
The current situation in our IdSrv4 implementation:
ADFS has been configured so that it emits the claims that we want and in our IdSrv4 implementation those claims are received as expected in the "ExternalLoginCallback" method of the AccountController.
IProfileService has been implemented in order to fill the "IssuedClaims" list with claims.
BUT, I haven't managed to build the connection between those to steps. What is the preferred way to preserve the claims received in "ExternalLoginCallback" and put them into the generated access_token in the IProfileService class?
Right now I have managed to get it working by saving the token using the method "UpdateExternalAuthenticationTokensAsync", which will save the token in the database. Then in the profile service I fetch the token and read the claims into the emitted token.
But this doesn't feel right and while searching for the proper way I´ve seen examples use the class IdentityServerUser that has "AdditionalClaims" property, but I can't find a way to plug that type into the event flow.
Also, when configuring the external IdP you have these "ClaimActions" that can be mapped, but I don't understand what they are.
Finally, I assume that the database tables "IdentityClaims" and "ClientClaims" with corresponding entities should be used for this purpose but I can´t figure out how. Or should they be saved in the "AspNetUserClaims" table to save the actual claim type/values and not only claim mappings?
So basically, there must be a best practice for this scenario that seem to avoid me and I would be greatful if someone could share it.
The main issue in my problem was that the problems I first encountered with persisting the Claims in the AspNetIdentity-Db led me to a wild goose chase.
Returning to this after a week or so made me give this another shot. Turns out that the DI injected "_userManager" wasn't "connected" to the current DI injected "_signInManager". If someone has an explanation for this, please share!
What did work was to use the "_signInManager.UserManager" to update Claims on the user. This properly stores the Claims in the "AspNetUserClaims" table, and can then be retrieved in the profile service.
UPDATE 1:
Of course there was a logical answer to that as well. A user manager is created by default even if you don't call "AddUserManager" on your identity setup during startup. BUT, in my case I have extended the IdentityUser class and now by doing it like this it all works as excpected (where "UserIdentity" is my derived class):
.AddIdentity<TUserIdentity, TUserIdentityRole>(options =>
{
options.User.RequireUniqueEmail = true;
})
.AddEntityFrameworkStores<TIdentityDbContext>()
.AddSignInManager<SignInManager<UserIdentity>>()
.AddUserManager<UserManager<UserIdentity>>()
.AddDefaultTokenProviders();
I need to declare 2 IDPs in spring-security-saml having the same entity id.
My webapp uses spring-security-saml.
This webapp is accessible by 2 differents URLs behind a reverse proxy.
The first URL is public, the second URL is filtered.
So, I declared 2 SP (one for each URL).
Everything was working properly with a single IDP (ADFS or Gsuite).
I also run the application properly with 2 SPs and 2 IDPs with an affinity SP1/IDP1 and SP2/IDP2 when IDP1 and IDP2 had a different entity ID.
Unfortunately by wanting to use Azure Active Directory, each SAML application in Azure results in its own IDP metadata with its own certificate, but with the same entity id.
So I need to declare 2 IDPs in spring-security-saml having the same entity id.
Reading the code shows that it is not intended to work like this (the entity id is used as key).
Do you have an idea to work around this problem?
Should Azure provide a unique entity id ?
I know it is too old but just found it but you can not use the same Entity ID per tenant for 2 different apps, so it makes sense that the apps have a different certificate even if they have same Entity ID because both apps are in different tenants
How it worked for me!!
As Spring saml works only for unique IDP entityIds. So to make it unique for 2 different IDP having same entity Ids, I prexied one of it with alias as i know what is that alias is for.
So now I have to hack entityID at certain places of initialization, validation during metadata loading AND in SAML response verification.
For metadata(one that has prefixed entity Id) loading to be successful especially one with signed metadata..
Created new child class MySAMLSignatureProfileValidator that overrides
SAMLSignatureProfileValidator.validateReferenceURI.
To use this I need to create another custom class SamlSignatureValidationFilter that extends MYSamlSignatureValidationFilter and initialise MySAMLSignatureProfileValidator in their constructor.
Use this SamlSignatureValidationFilter when we add metadata to metadata manager like this..
metadataProvider.setMetadataFilter(new MYSamlSignatureValidationFilter(metadata.getTrustEngine(metadataProvider)));
And now add another custom class MYSAMLCachingMetadataManager to override initializeProviderFilters and remove the logic to setMetadataFilter as its already set as in above code.
Use MYSAMLCachingMetadataManager in your config for MetadataManager.
This should take care of saml metadata loading.
Then coming to SAML Response that has the issuer as the original entityId, we need to add prefixed alias to the context here so that it verifies with our prefixed_entityId stored in metadatamanager entity list.
In this case I added MySamlHttpPostDecoder that overrides HttpPostDecoder.extractResponseInfo to add alias to messageIssuer.
And, MySamlWebSSOProfileConsumerImpl to overirde WebSSOProfileConsumerImpl.verifyIssuer to set issuer.getValue with alias. so later verification with stored entitId will match.
Use this MySamlWebSSOProfileConsumerImpl and MySamlHttpPostDecoder in your config. To use MySamlHttpPostDecoder I need to add new class MySamlHTTPPostBinding(ParserPool parserPool, VelocityEngine velocityEngine, MessageDecoder decoder) that extends HTTPPostBinding and pass MySamlHttpPostDecoder for decoder.
Hope it works for you too!!!
I've got AngularJS and Web.API WAAD authentication up and running. For client side I use great library ADAL.JS. For backend I use Microsoft.Owin.Security.OAuth. This part went quite smooth.
Now I want to implement authorization based on roles (which will be mapped to WAAD groups). Groups are not included in authentication token so I must ask Azure Graph API for them. I saw various ways to do it, using custom claims providers, adding web services to project, etc. Some examples already providing mapping between groups and roles to use in [Authorize] attribute.
But what is just the simplest example of how to get a list of group ids/names from WAAD providing User ID or username, when I'm already authenticated?
Also, is there any way to get this data in JS to use in Angular frontend, or should I create an API service which Angular should call for roles info?
In the non-JS case, the simplest way of getting groups in the token is by opting in. Download your application’s manifest, locate the “groupMembershipClaims” entry, change its value to “SecurityGroup” or “All”, upload back the manifest.
However note that this won't work for your scenario, because it uses the implicit grant - here the token is returned in an URI fragment, hence a big token would risk blowing past the URL length limits of the browser.
You can always request groups to the Graph and make it available to your frontend via custom action on your API, but from what you wrote you are already familiar with that. Let me discuss the matter here - if there's a simpler route to make this work in SPAs, I'll get back to this thread.
HTH
V.
Update: I verified and in the implicit grant case you will receive groups always via the overage claim. Please refer to https://github.com/AzureADSamples/WebApp-GroupClaims-DotNet/tree/master/WebApp-GroupClaims-DotNet - it will show you how to process the overage claim to retrieve groups. All you need to do is apply the same guidance to a web API instead, and if you need to make the info available to the client expose one or more actions doing so.
I want to have some restrictions on my endpoints API where even if a user is authenticated, they might not be allowed to perform certain actions. I'm mostly guarding against someone being malicious and writing their own client against my backend (my own client will never do what I'm guarding against).
However, I'd still like to be able to perform those actions as myself for debugging purposes.
A simple approach would be to hardcode some "admin" email addresses on the backend.
Is there a better way? Ideally, I'd want to be able to specify the list in the console, and then in code I could have some API on the google User class such as user.isAdmin().
Does such a thing exist?
Thank you.
Using endpoints, you have the opportunity to include a User object parameter in java or use from google.appengine.api import users in python and then user.get_current_user(). If the user is administrator, you can check this (python example) (javadoc for function isUserAdmin()). Do this inside your protected API functions.
You can read more about authorization in endpoints here. In general the docs are a great place to find this kind of info.