I'm working on my master where I have to design and prove a solution to expose some university legacy services. None of them have controlled access, so other feature needed is this security layer.
To make this possible I'm using wso2 products: wso2ebs to make some orchestration and messaging transformation; wso2is to connect to a shibboleth idp that already exists; and wso2am to put everything together and expose the services.
I already have the identity provider (Shibboleth) configured on wso2is. I use this http://xacmlinfo.org/2014/12/10/federation-testshib/ to prove it.
To make the authentication layer, I'm not sure but I think that I can use this http://wso2.com/library/articles/2015/03/bring-your-social-identity-to-perform-organizational-authorization-actions-with-wso2-identity-server/ to make the bond between wso2is and wso2am.
But there is a use case I can't solve: wso2am give me an oauth like environment to expose my private services, but how can a student (end user) manage is authorisations? I as a student which use a mobile app that consume information given by an api exposed by wso2am, want to revoke this this authorisations given previously to this mobile app. How can I do this?
TLDR:
If wso2am use an oauth like environment to expose apis, is there a way to the end user revoke an authorisation given previously to an mobile app that make use of an api exposed by wso2apim?
There are two options
If you have client_id, Secret and access token on your hand you can use https://docs.wso2.com/display/AM190/Token+API revoking access tokens part
If not you can use revokeAuthzForAppsByResoureOwner operation in OAuthAdminService
Related
I have a legacy system that has an existing login mechanism - assume it is a custom method. We have another set of services that require an oauth2 access token and use keycloak for generating and verifying the tokens. After a user logs in we no longer have access to their password hence I can not use the password grant to get them an access token to our oauth based system. What are the recommended approaches to generate this access token. What I have looked into so far:
impersonation (token exchange)
custom keycloak userstore SPI that validates user with blank password
I guess using a client credential flow to generate a token that tries to match the users roles and attributes.
It seems to be a use case that is not well supported by oauth2?
It seems to be a use case that is not well supported by oauth2?
Your use-case seems to match those defined in the OAuth 2.0 Token Exchange specification
One common use case for an STS (as alluded to in the previous section)
is to allow a resource server A to make calls to a backend service C
on behalf of the requesting user B.
For this approach, you will need to configure in the appropriate Keycloak realm your legacy system as Identity Provider. So that you create a trust-relationship between the legacy system and Keycloak. Afterwards, you can exchange the token coming from the legacy system (resulting from the user authentication) for a token of the aforementioned realm. Depending upon your setup you might need protocol mappers that map the legacy system roles to the roles in the Keycloak realm. All of this is assuming that your legacy system is to a certain extend Oauth2 compliant.
Otherwise, another approach is for your legacy system, to call a confidential client on Keycloak and pass along some claims (e.g., the user roles). This is assuming that your legacy system can securely store the client secret. All of this, of course, depends upon the concrete characteristics of your setup.
I have read rfc6749 and https://auth0.com/docs/authorization/which-oauth-2-0-flow-should-i-use but I couldn't seem to find the flow that's exactly for my use case.
There will be a native app(essentially a GUI) that will spin up a daemon on end user device. The daemon will try to call internal APIs hosted by the backend. The internal APIs don't need to verify the user identity; but it's preferred that the device identity can be verified to some extent. There will be an OAuth authorization server in the backend to handle the logic. But I couldn't identify which is the correct flow to use for this case.
Originally I thought this is a good fit for client credentials grant type. But then I realized that this might be a public client but client credentials is supposed to be used for confidential clients only.
I then came to find out about authorization code with PKCE flow. This seems to be the recommended flow for native apps but it doesn't make much sense to me as there will be redirects and user needs to interact but the APIs that will be called is supposed to be internal and user shouldn't know about these back channel stuff at all. Also the resource owner should be the same as the client in this case, which should be the machine not the user.
So which flow should I use?
Thanks a lot for the help!
Client Credentials feels like the standard option but there are a few variations:
SINGLE CLIENT SECRET
This is not a good option since anyone who captures a message in transit can access data for any user.
CLIENT SECRET PER USER
Using Dynamic Client Registration might be an option, where each instance of the app gets its own client ID and secret, linked to a user.
The Daemon then uses this value, and if the secret is somehow captured in transit it only impacts one user.
STRONGER CLIENT SECRETS
The client credentials grant can also be used with stronger secrets such as a Client Assertion, which can be useful if you want to avoid sending the actual secret.
This type of solution would involve generating a key per user when they aughenticate, then storing the private key on the device, eg in the keychain.
I have an old windows application written in VB.NET with SQL server backend. Currently the new user additions, deletion, adding entitlements etc. are managed by an old approval workflow system. After getting approvals, the user details and entitlements are inserted in to the SQL server database table manually.
I am trying to integrate this application with the SailPoint's Identity and access management. So the new user addition, deletion update and adding entitlements etc will be done through Sailpoint. For this, I would require to create a WEB API which can be called by Sailpoint and expose the functionalities(add user/delete user/add entitlements). The only consumer to this API is SailPoint.
I am new to OAuth and below are the grant types that I came across. But not sure which one I should be using in this particular scenario.
1.Implicit Grant
2.Resource Owner Password Credentials Grant
3.Client Credentials Grant
4.Authorization Code Grant
I have done research on the different authentication methods that we can use to secure the web api. But still confused on which one to apply in this scenario as this new web api is going to be made available in internet.
I already tried developing a POC with the OAuth 2.0 with password grant type referring this article. But when I read articles in the internet I found that the password grant type is not that secure and is deprecated.
Could you please advise on which grant type(client credentials/authorization code/implicit) to use in this scenario. I believe authorization code is used when the user is directly trying to access the API. In this scenario, SailPoint will be calling the API in the backend programmatically when they insert a new user in their UI.
I think it's a good approach to use client credentials in this case because the communication between IIQ and your Web API can be considered an API-to-API communication, I mean, IIQ is acting on behalf of itself in this communication.
See this article for more details - https://dzone.com/articles/four-most-used-rest-api-authentication-methods (bold part by myself)
OAuth 2.0 provides several popular flows suitable for different types
of API clients:
Authorization code — The most common flow, it is mostly used for
server-side and mobile web applications. This flow is similar to how
users sign up into a web application using their Facebook or Google
account.
Implicit — This flow requires the client to retrieve an
access token directly. It is useful in cases when the user’s
credentials cannot be stored in the client code because they can be
easily accessed by the third party. It is suitable for web, desktop,
and mobile applications that do not include any server component.
Resource owner password — Requires logging in with a username and
password. In that case, the credentials will be a part of the request.
This flow is suitable only for trusted clients (for example, official
applications released by the API provider).
Client Credentials —
Intended for the server-to-server authentication, this flow describes
an approach when the client application acts on its own behalf rather
than on behalf of any individual user. In most scenarios, this flow
provides the means to allow users to specify their credentials in the
client application, so it can access the resources under the client’s
control.
How do I best configure Keycloak so that a user needs to have an account for a client to be able to login into that client?
I have to replace a proprietory SSO-Impl. It deals with users, roles and clients much like Keycloak. However, it also knows about accounts. A user is only allowed to login to a client if he has an account for that client.
In Keycloak, if a user simply exists in a realm he may login to a client of that realm. Nothing else is needed. So no "account" is needed. In the old application, he needs an account as well.
What functionality in Keycloak is best suited to overcome this difference?
I have one idea:
Create a client-role in each client namend "HasAccount" and assign it to users. Then, restrict access if that role is missing.
This is discussed here: "Restrict client access in a single realm with keycloak"
It has at least two drawbacks:
It mixes authentication and authorization in the legacy app. I can understand that. But creating a role was already a workaround. That is why I described my initial problem here.
I have clients in 3+ languages/technologies. Adding functionality there seems like more work than in Keycloak.
Last remark:
Before you ask "This is not single sign on" anymore. It is only for administrative purposes. The admin can allow users to login into a client or not by creating an account or not. The user does not have to login a second time. If he is logged in in App A and has an account for App B, accessing App B works without logging in there.
A user is only allowed to login to a client if he has an account for that client. is really not a task for Identity Provider (IdP). It provides only identity and not authorization.
Of course you can ignore that and implement authorization as well. See: User attribute based web service access control by Keycloak
From the design perspective I would add auth reverse proxy in front of legacy app (but it isn't a best solution for SPA apps). Auth proxy will provide authentication via OIDC protocol and also authorization. Legacy apps may keep own OIDC authentication - it will be seamless auth from the user perspective, because SSO will be used.
Account entity - you can use group entity in the Keycloak instead of original account.
I'm trying to implement security to a backoffice CLI tool (NodeJS) that calls a REST api (Java/JAX-RS) for performing database operations etc.
As we're using Azure AD for all our user accounts I'd like to use it for authenticating our users and also for authorization.
The authorization is needed since not all members of the AD is supposed to use the CLI, and there are two types of users of the CLI with a different set of available commands, meaning that even if you are able to use it, some features might be locked out depending if you are an operator or administrator.
I've managed to create two applications in Azure AD, one for the CLI and one for the API. I can login using our AD credentials, fetch Access tokens for the CLI app id requesting the REST API resouce. On the client side I'm using https://www.npmjs.com/package/simple-oauth2 .
On the Java side the tokens are validated against Microsoft public keys, so everything seems to work out fine.
But, how should I lock down the users to either operator or admin roles? One naive way I can think of is to have the user/role correlation in the REST API and only use the OAuth flow for authenticating the user. But I guess that's what the AD is there for... Could OAuth scopes help me in this case?
Or should the REST API call the AD to query for users group memberships, once it receives the access tokens and knows the end user identity?
Thanks in advance!
Use the Application Roles.
Here you will find good description what application roles are and how to handle them:
https://learn.microsoft.com/en-us/azure/active-directory/develop/howto-add-app-roles-in-azure-ad-apps
The recommended resources at the end and also very helpful and will guide you through the process.
Also, when developing CLI it is recommended to use the Device Flow - described here with sample code (.net core) here.