I am currently building a microservices based application in spring boot with the following services
Auth server (Distributes access tokens)
User service (User info like username, password, email, etc.)
Various other unrelated services
When a user sends their credentials to the auth server, the auth server should verify that they are correct and then return an access token.
My question is, should I combine the auth server with the user service so looking up credentials is a simple database call, or should I keep them as separate applications and have them both point to the same shared database? Is there a better alternative?
What I usually do is keep them separate. Account information (first name, last name, contact data, affiliation, sex etc) is not related to authentication/authorization. Also, an account can have multiple authentication methods (i.e. OAuth, uname-pass, private key), which isn't really related to account data. So, I take them as separate entities. I know auth and account data seem the same, but they represent two very different things, with very different responsibilities, so I keep them separate. If one user should have to see some other user's first and last name, I wouldn't like to get other user's credentials out of the database (a lot can go wrong).
If you are thinking of UserService from Spring Security, it goes with Auth server.
From security stand point, having a single point of truth (auth server) and be able to fix an issue in one place is a huge advantage.
Anyhow, IMHO, account and auth can share some properties, but they are two different things - hence I keep them separate.
Hope this helps.
You should keep them separated, oauth is not related to identity management but to authorization delegation.
In oauth2 there are 4 roles (resource server, resource owner, client and authorization server) you are currently asking if the authorization server must be part of one microservice of the resource server which has absolutely no sense.
If I correctly got your case what you name a user corresponds to the resource owner role in oauth2 terminology, some oauth2 flows (e.g. client_credentials) directly allow a client to get an access to the resource server and there will be no users implied in any way.
Related
Hello fellow programmers.
I hope there are some keycloak experts out there that can help me to solve my question.
So my situation is that we have microservice platform with ~20 services which in the future should be secured using keycloak jwt tokens.
The idea is that we offer an interface for our clients where they can register themselves with a password/key pair within one realm and they should be able to use that account to access all the
services through a public facade/api.
Now to the question - how to handle the client id - in all examples each service has its own specific client id - should this in our case be the client id of the public api//facade which allows the inner services or is there better approach how to handle this without forcing the user to log in for each service...
Thanks in advance for all help and I hope you are all doing well...
Gerrit
P.s. Maybe to clarify my question further - my current understanding is that for each. service i should add a new client to my realm but my users then would need to get a token for each service/client as each client owns his own secret... and I want my users to be able to use one token for all our services.
So after wrapping my head around this issue and reading the docs:
clients
Clients are entities that can request Keycloak to authenticate a user. Most often, clients are applications and services that want to use Keycloak to secure themselves and provide a single sign-on solution. Clients can also be entities that just want to request identity information or an access token so that they can securely invoke other services on the network that are secured by Keycloak.
I think to use one client for my user accounts for the whole platform is the proper way to go.
Would be perfect if one of the keycloak experts can acknowledge this.
I'm trying to figure out how to migrate a system that is currently using ACS to Azure AD. I've read the migration docs provided by Azure and have looked through the Azure AD docs and the sample code but I'm still a bit lost as to what the best approach for my situation would be.
I've got a web API that has about 100 separate external systems that connect to it on a regular basis. We add a new connections approximately once a week. These external systems are not users--these are applications that are integrated with my application via my web API.
Currently each external system has an ACS service identity / password which they use to obtain a token which we then use to authenticate. Obviously this system is going away as of November 7.
All of the Azure AD documentation I've read so far indicates that, when I migrate, I should set up each of my existing clients as an "application registration" in Azure AD. The upshot of this is that each client, instead of connecting to me using a username and password, will have to connect using an application ID (which is always a GUID), an encrypted password, and a "resource" which seems to be the same as an audience URL from what I can see. This in itself is cumbersome but not that bad.
Then, implementing the authorization piece in my web API is deceptively simple. It looks like, fundamentally, all I need to do is include the properly configured [Authorize] attribute in my ApiController. But the trick is in getting it to be properly configured.
From what I can see in all the examples out there, I need to hard-code the unique Audience URL for every single client that might possibly connect to my API into my startup code somewhere, and that really does not seem reasonable to me so I can only assume that I must be missing something. Do I really need to recompile my code and do a new deployment every time a new external system wants to connect to my API?
Can anyone out there provide a bit of guidance?
Thanks.
You have misunderstood how the audience URI works.
It is not your client's URI, it is your API's URI.
When the clients request a token using Client Credentials flow (client id + secret), they all must use your API's App ID URI as the resource.
That will then be the audience in the token.
Your API only needs to check the token contains its App ID URI as the audience.
Though I want to also mention that if you want to do this a step better, you should define at least one application permission in your API's manifest. You can check my article on adding permissions.
Then your API should also check that the access token contains something like:
"roles": [
"your-permission-value"
]
It makes the security a bit better since any client app with an id + secret can get an access token for any API in that Azure AD tenant.
But with application permissions, you can require that a permission must be explicitly assigned for a client to be able to call your API.
It would make the migration a tad more cumbersome of course, since you'd have to require this app permission + grant it to all of the clients.
All of that can be automated with PowerShell though.
If I set up composer-rest-server to use github authentication (as described in https://hyperledger.github.io/composer/latest/integrating/enabling-rest-authentication.html), then a client of the rest server needs to authenticate against github.
If this authentication is successful, then the client acts with the business card that was specified during startup of the rest server (or with the one that was uploaded in multi-user mode).
However, ANY github user may authenticate that way! There is no control which github users may use the rest server (I would expect a configuration file with a white list etc.). Therefore ANY github user may interact with the blockchain the same way using the business card of the rest server?!
This is quite useless in my opinion. Or do I oversee something? What is the purpose of github authentication in composer-rest-server?
Before authentication there is no real access to the Business Network, after authentication there is access to add Cards to a Wallet after which there is access to the business network (controlled by ACL).
The Wallet is unique to the authenticated user, so in your github example if you open a different browser and use a different Github ID you will have an empty Wallet, and no access to the network - except to add a card.
With regard to Github it is just used as an example of a Passport Strategy for Authentication - it is used in the example docs as it is quite easy to set up and anybody can use Github. It might be useful for a public blockchain, but for many examples it might be more appropriate to use a Passport Strategy to connect to a private LDAP or Active Directory.
I need to be able to store a user's Exchange password so I can use it to perform some task later on, using EWS. I know storing passwords in plain text is a horrid crime, so what options do I have?
In my case, my application will have access to an administrative account that will have the ability to use impersonation to work with users' Calendars. I need to store the password of this admin account so I can use it while authenticating with the Exchange server at a later time. I am not planning on using the EWS Managed API.
I have a user that created a calendar app with similar requirements. By default, an account that has these permissions globally is horrible and not recommended. Impersonation roles were granted by department that required access to the app to reduce risk scope. However if you require this globally, here's what I recommended for mitigating the account/password exposure:
Restrict the accounts functionality to Exchange services only. Features like log on locally and other general domain user privileges are not needed for an EWS service account that only needs mailbox access and impersonation roles. In this case, the account cannot log onto a computer nor can it be used for RDP. This limits exposure for malicious use.
The user/pass can be stored in your applications database and the connection string would also be stored outside of your application, there's a lot here: https://security.stackexchange.com/questions/22817/how-to-encrypt-database-connection-credentials-on-a-web-server and encrypting the password within the database; further reading: http://www.darkreading.com/safely-storing-user-passwords-hashing-vs-encrypting/a/d-id/1269374
Restrict DB server and management access. This is a larger issue than it should be if the database server is shared between groups. Audit the database server access, and re-restrict if you have too many cooks in the kitchen. The database server should also not be directly accessed by user networks but that may be a larger issue to tackle.
Restrict access to the application. As in, is it available externally or only available inside your perimeter? Either way, the application should also include authentication just to access, using Kerberos or some other SSL auth, make sure the application cannot be used to DoS the EWS services from over-access.
Create a one-off throttling policy on Exchange for this user and assign accordingly to prevent the application from breaking EWS or limiting regular user functionalities. This is something Blackberry admins learned the hard way if they didn't follow recommendations. When BES server wouldn't properly tear down connections, web services would start dropping valid client requests. As such BES had to instruct users to create a one off throttling policy for various Exchange features. I did the same for the user that created my EWS app. And a few times it saved me.
Really it will boil down to good application design and coordinating requirements with the Exchange team.
Don't's:
Don't store the username/password in Apache/IIS pages or the connection string
Don't grant global permissions for the account if you don't have to
Don't allow unauthenticated access to the application and allow unlimited connection times
Hope this helps.
I' new in implementing a RESTful web service. I need your opinion to understand if my idea can work. I want take separate the authentication database from the resources database (the main one, with all the user stories). I put them in two different web servers. The clients ask their token to this primary interface (the auth server) that replies the generated token (if login is valid) and at the same time the authentication server sends the userID and userToken to the resources database server.
The client has received the token, it means it's logged in and it can makes requestes of resources to the resources database server. It appends its userToken to prove its identity. The resources database server checks the userToken and if it's not expired, it replies with the requested data to the client.
I've tried to explain the concept with two images.
I would like to understand if this is a good implementation of an authentication process. I really care about the security, performance and flexibility. What do you think about this?
Do you have any suggestions related on this? Thank you very much.