We are planning to use ejbs for our service layer. We have http clients and EJB clients.
We want to authorise a user action based on his roles. There are two kinds of users, admins and non admins.
We configured a realm in the server and in the web tier the SecurityContext is populated by the server.
We want to basically write an interceptor and add it on the service methods. Whenever an ejb method is called, irrespective of from which client layer the method is called, the interceptor should be able to get the user name/id so that it can check for authorization.
Can anyone help me how to solve this?
Related
We're using Keycloak server for authenticating against several IDPS (google, active directory, etc). We have a spring gateway microservice which plays role of a client and several other microservices which play role of resource servers.
When user authenticates via keycloak, we want to associate the authenticated user with some custom fields (like context, roles, user details) from our custom database (NOT Keycloak DB) and send those fields to other microservices as well, so that we do not need to load the fields from DB in every microservice.
How would you do that? Making a GlobalFilter in the Gateway which would add those fields to request headers and setting those headers somehow to the principal object in resource servers? Or using cache (redis) to store the fields on gateway and load them in resource servers? Or do you have some other solution? For example extending access token, overiding UserDetailsService, etc..
What's important to note is, that we don't want to extends Keycloak Database, since we want to have the whole role management in our custom database. Reason for that is that keycloak schema is not very flexible. We want to use keycloak only as a dummy authentication server.
The preferred option for security related values is for Keycloak to reach out to your APIs or custom data sources at the time of token issuance, then include your domain specific claims in JWT access tokens. In keycloak I believe this is done via a protocol mapper, as in this answer.
This design pattern is discussed in the Claims Best Practices article. It is recommended to not send secure values such as roles in custom headers etc, since they are potentially easier to change by a hostile party. Instead each API should receive the JWT and validate it, in a zero trust manner, then use the received claims for authorization.
For non secure values, such as a session_id or correlation_id used for logging, simple HTTP headers work well.
I am designing a service oriented application where the communication to the database is distributed across multiple services (Authentication service, some service for auditing and other for accessing the db and doing CRUD operation ... etc).
Say a user login to the app using his id and password, the app then talk to the auth service and find out if the information are correct, once done the user want to insert some data, now the app use another service to fulfil the user request. How can the other service now that the user is an authorized user to use the service.
Your use-case seems very similar to what SAML addresses.
Also look at OAuth.
If these standard mechanisms don't work for you, you can at least develop a mechanism where:
The authentication service returns a token on successful login. The
caller app should then be able to use this token to access the data
service and other services.
The data service should be able to independently validate the token (possibly with the authentication service).
You might want to ensure that the tokens remain valid only for a certain duration or certain number of invocations
What this avoids is the need for every back-end service to allow access to the app without using your login details.
Also see: What is token based authentication?
I have two different client apps written in javascript connecting to two different web api. I am trying to implement identity server 3.
Is it possible to have identity server behind my web api owin
authentication api end point. In other words, is it possible to
route /token endpoint from owin in web api to call /authenticate
endpoint in identity server?
Is it possible to audit log to db in identity server including
failed request along with user's ip and browser agent. Also is it
possible to log user's ip even if i am calling from web api as my
web api is being called by a user using browser?
In my case should i keep two different user base for two different
projects or move all my users to identityserver. If i move all the
user info to identityserver, how am i going to handle all the joins
with other tables in different applications or should i keep a copy
of user with minimum info such as id, email and name?
It makes little sense to first call a web api and deal with authentication during that call.
Your client apps should first redirect the browser to IdentityServer where user would log in and be redirected back to your client app along with either access token (implicit flow) or authorization code (AuthorizationCode flow), depending on the client app having a back-end or not. Then, your client app would make requests to the webapi, passing the access token in the Authorization header.
As for different user bases, one approach might be to implement specific IUserService for each user base and either send a hint about which one to use in the acr_values or tie it to specific clients registered in IdentityService. Again, depending on the requirements.
Is it possible to have identity server behind my web api owin authentication api end point. In other words, is it possible to route /token endpoint from owin in web api to call /authenticate endpoint in identity server?
Yes and no - you cannot reroute those requests, but you can host identityserver in the same application as a web api. In Startup.cs, map a folder to identityserver.
It's not a good idea to do this, first of all, which api of the two will host idsrv? What if that api goes down and takes idsrv with, then the other api does not work anymore.
-> host idsrv separately, make both apis and both javascript apps clients in idsrv, login to idsrv from the javascript apps (=SSO) and use bearer tokens for the api
Is it possible to audit log to db in identity server including failed request along with user's ip and browser agent. Also is it possible to log user's ip even if i am calling from web api as my web api is being called by a user using browser?
Yes, this should be possible, check the logging implementation for idsrv, at the least you should be able to plug in a provider that writes to a database.
In my case should i keep two different user base for two different projects or move all my users to identityserver. If i move all the user info to identityserver, how am i going to handle all the joins with other tables in different applications or should i keep a copy of user with minimum info such as id, email and name?
Idsrv does not need to have all the user info, just an email-address is enough, you can use that as link to the user data in your api databases if you use that as unique identifier.
We have an existing Java EE application running under WebLogic and I want to authenticate a user programmatically as though the user was logged in via the existing web login process. That is to say, in the end, I want to have a valid session (cookie) that can be returned to the caller and later returned back the server without re-authentication. (This is to enable JAX-WS stateful Web Service calls).
We have a custom LoginModule that, when the user logs in via Forms Authentication, is eventually called via j_security_check. I guess what I'd like to do is to somehow get WebLogic to invoke that LoginModule on my behalf, ask me for the credentials, and yield an authenticated session and a valid subject etc. (i.e. all the JAAS goodness).
Is this a JAAS thing? Is there a WebLogic call?
You can do this using the HttpServletRequest#login method. This will trigger the same kind of login chain that would otherwise be executed if your used accessed a protected resource.
WebLogic security uses a security service plug-in (SSPI) architecture that allows you to implement security providers. Container (such as servlet) authentication is handled by authentication providers that use the SSPI. An authentication provider wraps a JAAS login module.
Writing and configuring security providers is extensively documented.
If you implement an authentication provider to wrap your login module and configure it for the WebLogic domain, it will be called automatically by the WebLogic security framework for all container authentication.
I need to propagate the Windows Identity of the current user across two service calls.
Service A (which runs under integrated authentication) calls Service B (which also runs under integrated authentication). I need to identify the user identity which was used to call Service A in Service B's code.
I know this is possible using delegation, by impersonating the User in Service A code and then call Service B from the impersonated code.
However, I only want to flow the identity and not impersonate the user. Is this possible without impersonation?
get the authenticated user using ServiceSecurityontext.Current.PrimaryIdentity.Name
Add this as either a header or a field in the downstream service request
I think you are looking for the impersonation level called "Identity". See this article for a description of different impersonation levels in WCF.