After configuring various realms, I'm trying to figure out if it's possible to customize the "/.well-known/openid-configuration" endpoint for each realm.
The goal is to modify fields such as:
grant_types_supported
** _ alg_values_supported
** _ auth_methods_supported
and in general the fields present in the json.
I couldn't find anything in the official documentation or internet in general
Related
I have keycloak on docker (v20.0.2) and as you know some versions change some or good part of the UI, so is hard to follow tutorials around the web...
I am trying to follow this particular tuto
https://developers.redhat.com/blog/2020/11/24/authentication-and-authorization-using-the-keycloak-rest-api#keycloak_sso_demo
that seems the more updated. My keycloak is actually behind traeffic and thomseddon/traeffic-fordward-auth with a docker-compose file (but the connection through traeffic is good and I have acces to admin UI)
So on step 10 of the tutorial things change for me, I have to look for that particular view inside:
Click on lateral menu Client Scope
Click on button Create client scope
Give a name to the scope, and click on Tab Mapper
All mappers are predefined... so there is no "New mapper" don't understand this bit
then just follow the tuto
With that series of steps I get an error when retriving the token...
https://keycloak:8443/realms/education/protocol/openid-connect/token
enter image description here
(this are fake local data from the realm I created for testing)
that responds with a or something similar I have also tried to change the grant_type to password, and the same happens can not query the token....
{
"error": "invalid_client",
"error_description": "Invalid client or Invalid client credentials"
}
But if I do not link a user with an scope/role as in the tuto suggest then I get the token, but of course I want to use the role or scope to limit who can see which endpoint and who can not
Any step that I'm missing from this update, do you have the same error?
Thank you in advance
I have tried to run it with different combinations of options to see if there is a toggle that actually allows me to fetch the token
Also with different types of grant_type
I will build an API in Python (I don't know Java and prefer Json instead of XML) that connect to this keycloak to allow users or not based on their scope/role/permission or something
I need to be able to block user so if user Student try to access an url from another Student he get blocked that url. So is based on the role or scope or I don't know which is prefered or easer to accomplish, the mission is to block users or not based on a factor that could be used for this in keycloak.
TL;DR - Is there a way to get a bearer token with a custom audience (and perhaps authority) from the new SSO stuff in an Office.js?
Details -
We're trying to use the new SSO stuff for an Office.js add-in, but we're running into the problem that the bearer token from OfficeRuntime.auth sets the audience to the GUID for our add-in; we want to set a different audience (our API application) like we used to with MSAL, but there doesn't seem to be any option for that. We're using getAccessToken from OfficeRuntime.auth:
const token = await OfficeRuntime.auth.getAccessToken({
allowSignInPrompt: withUI,
allowConsentPrompt: withUI
});
(withUI is just a true/false flag we send the function this is in depending on whether showing a UI is okay.)
The options documentation doesn't show an option for "scope" or "audience" (or "authority") that we can see. Granted this stuff is all preview, so it could be a matter of "it's just not in there yet."
Our setup is:
+−−−−−−−−−−−−−−−−−+
| Browser / Excel |
+−−−−−−−−−−−−−−−−−+
| |
| +−−−−−−−−−−−−−+ +−−−−−−−−−−−−−−−−−−−+ +−−−−−−−−−−−−−−−−−+
| | Our add−in |<−−−−−>| Server w/ our API |<−−−−−>| Microsoft Graph |
| +−−−−−−−−−−−−−+ +−−−−−−−−−−−−−−−−−−−+ +−−−−−−−−−−−−−−−−−+
| | ^
+−−−−−−−−−−−−−−−−−+ |
v
+−−−−−−−−−−−−−−−−−+
| Azure DB |
+−−−−−−−−−−−−−−−−−+
Our add-in is set up as an Azure application and, separately, our API server is set up as an Azure application. The add-in has access rights to the API; the API has access rights to the various things it needs to satisfy API calls. That way, the relationships between the pieces are visible in the Azure configuration.
When we found we couldn't use the token from SSO, we looked at its contents and that's when we realized the audience wasn't what we wanted. For now we're working around it by adding the add-in's audience and authority to the options in the API project's authentication step:
services.AddAuthentication(JwtBearerDefaults.AuthenticationScheme)
.AddJwtBearer(options =>
{
Configuration.Bind("AzureJwt", options);
// These next two are the ones we had to add to make it work
// when we realized there was an audience problem
options.Audience = "guid-for-the-add-in";
options.Authority = "https://login.microsoftonline.com/relevant-guid-here/v2.0";
});
But that feels like a workaround rather than a solution; our Azure config doesn't represent what's going on, we have hardcoded authentication instead.
Apologies if some of my terminology is off. Azure is new for me (though not for another member of the team).
This behavior is by design. For Office SSO, the web API has to be the same domain and AAD GUID as the add-in.
If you want to keep them separate, then the workaround you've found seems pretty good. (I'm surprised that you found a way.)
<highly speculative>
You might also want to try putting the add-in's GUID in the Authorized Client Applications section of the API's AAD registration.
</highly speculative>
It turned out to be a really silly mistake: We were bothered by having to specify the audience and authority in the API project (in the code in the question), but it turns out we were already specifying them in the API project — they were defined (with different values) in appsettings.json. So the code we added just overwrote them with the correct values.
Changing appsettings.json's Audience and Authority settings, and removing the code overriding them, worked just fine. So it was already a bit hardcoded (or at least not controlled via AD), just in a config file rather than code.
I've got Keycloak setup and running with NodeJS.
I see you can create groups and assign attributes to those groups. Is it possible to access these attributes from the NodeJS application?
I can't even find the groups let alone their attributes.
Yes you can. But there is almost no official documentation on how to achieve this. You can return most keycloak attributes, groups and roles through the client mappers. By default none are configured.
To configure extra mappers: In the administration console, select the client and then the Mappers tab. That should bring you to a list of mappers.
You can add mappers here of different types. Once you add a mapper you can decide which calls to Keycloak from the client return the attribute(s), and what the name of the returned attribute is. The following screenshot includes a mapper that returns a dictionary of groups, with subgroups, separated by forward slashes. Your Node code will need to parse the returned JSON object.
All the information is returned in the keycloak token, which is a Javascript Web Token. In Node you can examine it by printing the token to the log. The keycloak-connect middleware stores tokens etc in an object on the request called kauth. The path to retrieve a list of groups specified by the configuration in the above screenshot is shown below. If you change the token claim name in the configuration, you will need to change the path in your NodeJS code accordingly. You will need to logout from your application and login again for changes to the mapper to work.
router.get('/', async function(req, res){
console.log(req.kauth.grant.access_token.content.groups) ..
}
I have a website that uses Symfony2.8; I am working on a mobile app that would use the same project as the backend so I need to support token based authentication as well as regular login forms. All resources I've found talk about API only authentication not API(token based) and form. Anyone has any ideas how to accomplish this?
I am using FOSUserBundle if that matters.
You can do it by using custom Authenticators for each case.
Symfony 2.8 introduced Guard, which makes it's relatively easy to create custom Authenticators.
Basically you create 2 custom Authenticators , which essentially means creating 2 Services.
FormLoginAuthenticator -> app.form_login_authenticator
ApiTokenAuthenticator -> app.api_token_authenticator
Once these services are created, you just have to register those as Authenticators
in app/config/security.yml
security:
...
main:
anonymous: ~
knpu_guard:
authenticators:
- app.form_login_authenticator
- app.api_token_authenticator
entry_point: app.form_login_authenticator
Obviously it's upto you to implement those Services, but Symfony Docs does provide a decent starting point for you to start .
Check these links for the same :
How to Create a Custom Authentication System with Guard
How to Use Multiple Guard Authenticators
https://knpuniversity.com/screencast/guard ( provides fully working example + tutorial )
I'd like to restrict a user's access to just a specific node within an AEM website. I want them to be able to manage a blog; they should be able to view the blog (of course), add/edit/delete entries/comments, upload photos, add/remove other collaborators, etc. However, I don't want them to have access to or even see anything else within AEM.
I have tried giving access to just the blog node under the content path (/content/geometrixx/en/blog), but when I try to log into AEM as this user and edit the blog (localhost:4502/cf#/content/geometrixx/en/blog.html), I get the following error:
No resource found
Cannot serve request to /cf in /libs/sling/servlet/errorhandler/404.jsp
I've tried giving write access to the /content/geometrixx/en/blog node and read access to everything else, and it seems to work, but of course, the user is able to see way too much. It would seem there is some particular node that a user must have read access to in order to edit content nodes, but I'm not sure what that is. Any ideas?
I would go to the /useradmin, chose the user, and in the Permissions tab I would allow access to the below and its child pages:
/content/geometrixx/en/blog - allow read modify create delete replicate
/apps/geometrixx/ - allow read only
/etc/designs/geometrixx - allow read only
/libs - allow read only
/etc/clientlibs - allow read only (optional)
/etc/workflow - allow read only (optional)
This is roughly the solution I use in our setup. As you are aware, you need to give at least read-only to the directories where cq components sit, as well as the components from your application, in this case geometrixx.
edit: Also useful to read: https://helpx.adobe.com/experience-manager/kb/CQ53ACLsMappingToCRX2.html
Most importantly you really need to understand the different pieces of functionality of cq, where they reside (/libs, /apps/, /etc/, etc...) and what is required to have a page properly rendered.
Is it a requirement you have for both author and publisher?
Reading https://jackrabbit.apache.org/api/2.2/org/apache/jackrabbit/core/security/authorization/GlobPattern.html can also help you set ACLs.
I suggest you create a custom group with deny jcr:all on /, and then set the ACL as described by dex and test to see if it helps.
can you try to give the modified access instead of read access,
/content/geometrixx/en/blog - allow read modify
As you need access to single blog node and its jcr:content