I've set the groupMembershipClaims property in an app's manifest in Azure AD to "All", which should result in a user's security group memberships to be returned in the id token.
However, they are not being returned. Have tried to re-login multiple times. Is there something I am doing obviously wrong?
Can you be more specific in terms of what exactly you are trying to achieve and how'd you want to do it.
Apparently, if the thing mentioned in your question is what exactly you are looking for and since the groupMembershipsClaims property is set to "All", you'll get the group claims in the JWT token.
You may want to read this article https://www.simple-talk.com/cloud/security-and-compliance/azure-active-directory-part-4-group-claims/ . This should help you resolve your issues.
Let me know in case you face this issue after you follow the procedure mentioned by the author.
Sorry for wasting people's time here. I was asking this question for a friend, and turns out they were looking at the access token, not the id token.
So as future reference, make sure you are requesting an id token from AAD, and use that to figure out things like group memberships.
Maybe another note for future reference.
As JWT tokens are used in Authorization headers, you hit a limit of maximum 6 groups in the token.
If the user has more groups they will not be returned and you will have to implement the Azure AD graph API to fetch the groups of the user.
Related
I have a user permission system in place where i have a set of permissions within the database, for example
id
Permission
1
POST:CreateBooking
2
GET:AllBookings
And i have another table (junction table) where i put dependent permissions such as
if i want to create a Booking, i need to fetch Package details and so POST:CreateBooking requires the user to also have GET:AllPackages permission.
There's a template system in place as well, where the users can group multiple permissions together and once that template is assigned to any employee, that employee will get THAT set of permissions and it's dependent permissions.
What my nodejs system does is that when user logs in, it fetches all permissions from DB and puts it in a redis set from where on each request, the permission is checked against user id.
Is there any tool from where i can do exactly this but in an intuitive and better way?
I tried keycloak but i don't know how to cover my needs mentioned above.
Thank you
if I'm understanding correctly and trying to generify your scenario, you have a classical situation where:
You have groups which can have multiple permissions assigned;
groups can be created dinamically;
each permission correspond to a specific functionality.
So, implementing the OIDC (Open Id Connect) protocol might fit you needs. As you suggested youself you might be interested in a OpenID provider (do not reinvent the wheel) keycloak is good, you can give a look also to Vault Hashicorp.
So assuming that your backend have an already existing framework to handle security and permissions (eg. Spring Security) you can produce JWT token with the OpenId provider and check throught PreAuthorize claims (permissions) inside the token.
At the end your security layer it's just an annotation you need to insert before your method controller or before you class controller.
Behind the scenes, instead, this is what will happen:
Your user connect to your app;
User insert username and password -> the Open Id provider gives you a JWT
Your Front End app everytime it make a REST req will send also the JWT
The back end controller method called it's under authorization
Given the public keys of the OpenId provider, the validity of the token it's enstablished
If the specific permission claim it's found inside the token, the request can be elaborated else a 403 Forbidden it's returned.
OIDC - as the conceptual model/backdrop to any tool of choice, is certainly a popular/good choice, but as long as you're willing to deal with an element of complexity - the understanding required to implement an OIDC arrangement (- think of it as a possible investment - effort up front with hopefully the rewards tricking-in over time); e.g. OIDC is an ideal choice for supporting SSO (Single Sign On), especially when it comes to supporting/allowing for authentication/login via providers such as Facebook, LinkedIn & Google, etc (- as well as more Corporate OPs (OIDC Providers) including AAD/Azure AD).
Try to first step-back, and consider the possible bigger/future picture, before selecting a tool based upon only your starting/current requirements.
I have a web-application secured with Keycloak. To keep the description of the service short, we have Users and Documents as entities in the service. The users may have access to none or more documents and may edit or read the document.
Currently we have roles such as Admin, EndUser, Developer etc. We then keep a database table outside of Keycloak that maps the documents to users and what user has what access level to what document. All our end-users have the EndUser role in Keycloak. Every single time an EndUser tries to read/edit a Document, we have to make a lookup in the database table for authorization.
We would like to migrate that table to Keycloak. As I understand it I basically have two options:
Create a lot of roles, two for each document with names such as doc_read_[DOCUMENT-ID] and doc_edit_[DOCUMENT-ID] and so on. Then assign the correct role to the correct user. The downside here is that the number of roles will grow A LOT. Also, the number of roles attached to a user will be very large.
Create a group for each document, with the name of the document id. Have different sub-groups for read/write and then add the users in the correct groups. The downside is that the number of groups will be very large. Also, I will rely Authorization on group names, so the list of group names has to be mapped to the token.
I do not want to add a user-attribute with the document-ids to each user. With this approach I can not get an overview of a document and see what users have access to a given Document.
What is the best practice here? Are there any other solutions to solve this issue? This must be a very common setup.
This is just my opinion.
From what I understand both solutions are suboptimal, adding a role per document is unnatural and too finer grain. And as you already mention this would lead to too many roles that probably you will have to add them into the token.
I would personally use Keycloak just for the authentication part and do the authorization part in the backend. I would also try to group the documents in a way that reflect which user roles are allowed to manipulate them.
Alternatively you might try to use Keycloak's Authorization features to handle that use-case, however I have never used it, so there is not much that I can say about this option.
In my opinion what you want to achieve is something that is very tied to your business logic, I wouldn't recomend depending on keycloak to do it. Your token would constantly grow and management would be a nightmare really.
I see no problem in having a service with good cache to lookup permissions, the bulk of the data won't change much over time.
I am trying to retreive/change the MFA number on a B2C account programatically. I don't really mind how its done, and I am aware of this SO question - https://stackoverflow.com/a/40858874/243905 but that was asked a long time ago and I had hoped it was different now.
I find the B2C docs are a bit lacking in clarity on this information, and although I am able to query the users using the method detailed here: https://learn.microsoft.com/en-us/azure/active-directory-b2c/active-directory-b2c-devquickstarts-graph-dotnet
the object that is returned does not return the MFA details.
Is this possible through any means?
strongAuthenticationPhoneNumber can be issued in the resulting token, however it can't be edited using graph, for the moment. It's expected this capability will be available during the 2nd half of 2018.
As of today this appears to be working for Azure B2C. Microsoft Docs
There is an extra permission that the token will need. UserAuthenticationMethod.ReadWrite.All
Say I want to use JWT for authentication, and in the case of users who are using the API of my application directly I would like to issue a token that does not expire (but does contain an ID so that it can be revoked). Secondly, say I have a role based access system, where I would also like to encode the user's role into the token. However, how do I solve the problem that the user's role may change but that the token would still encode it? Obviously if someone's role changed to some thing with less privileges this would be a security issue? The issue isn't just restricted to this use case either, theoretically active tokens would have the same problem of role changes not taking immediate affect.
My initial solution is too not encode role/permission levels into the primary token, and instead use a secondary token that would only be added to request to my system upon passing through the application's boundary from the greater internet, but I'm also wondering how other people solve this problem?
If you need to invalidate tokens, you'll have to keep track of the tokens you issued and make sure you can "remove" them at some point in time.
My suggestion would be to use one token, and track somewhere a relation between USER and TOKEN_VALID_IF_ISSUED_AFTER.
At that point, when a user logs out, when their permissions change, when they change password... ...you can insert a record in this table with $USER_ID and NOW().
Next time a token goes through your API you validate that it was issued after the TOKEN_VALID_IF_ISSUED_AFTER through the iat claim -- if not, the user will have to get a brand new token.
I am trying to validate a SAML token that was created by our WIF-based custom STS inside a REST web service.
There are a couple of functions to do validation. One is SecurityTokenHandlerCollection.ValidateToken() and another is SamlSecurityTokenAuthenticator.ValidateToken().
Unfortunately the online Microsoft MSDN help for these classes and functions is worthless and does not describe at all what it is these functions are doing.
What are these functions validating and how are they doing it? What are the differences between them? Are they automatically looking up the certificate in the Windows Certificate Store to check the signature of the token, and validating the encrypted credentials object? Because I don't pass a certificate name in anywhere. Or are there other manual operations I need to do myself to validate the token?
I realize one returns a ClaimsIdentityCollection and the other returns a collection of IAuthorizationPolicy objects. But is that the only difference? I can't tell.
I can find plenty of information out on the web about the STS and claims and even validating claims, which I am doing successfully, but I can hardly find any information on validating the token itself to make sure it is one I created.
In most cases you don't need to worry about the token validation details. All this is taken care for you by WIF.
But if you really want to know, the best source of information is Vittorio's book: http://www.amazon.com/Programming-Windows%C2%AE-Identity-Foundation-Dev/dp/0735627185
There are some details here: http://msdn.microsoft.com/en-us/library/ff359114.aspx
Another good way of learning is by looking at the extensions built to handle non-SAML tokens (e.g SWT). Download the samples here and look for the REST services.