I have a setup with Tivoli Access Manager (TAM) as reverse proxy for some application servers on the backend side. TAM is responsible for authenticating users. Is it possible to access the credentials a user passed in during TAM authentication in the backend applications?
I need this because the backend applications connect to a Host-System and there the credentials are needed to log in.
there are a couple of options you might have for this :
Since you mention TAM, I guess you are still using 6.X, so you can use a custom CDAS (Cross-domain Authentication Service) library. You would need to implement the library yourself in C and handle the authentication part and return the clear text password as an extended entitlement in the credential. This will allow you to add this extended entitlement as an injected HTTP header for the junctions that require the password. You can get more information here : http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_web_devref58.htm%23chap-wsd-write-custom
You can implement your own External Authentication Interface. EAIs are external web applications where WebSEAL can delegate the authentication part. In that EAI, as in CDAS, you would have to handle the authentication part yourself - probably against TAM user registry - and then return the clear text password as an extended attribute in the credential to be used as a custom HTTP header for the junction that requires it. See http://www-01.ibm.com/support/knowledgecenter/SSPREK_6.1.0/com.ibm.itame.doc_6.1/am61_web_devref128.htm%23appx-wsd-eai
Leverage Tivoli Federated Identity Manager and a custom STS chain to do the authentication and return the clear text password as part of the credential.
For all 3 of the above options, you would need to modify the existing backend application to read the injected HTTP header and use the clear text password to perform the actions to the Host.
I have done all 3 for various integrations and I think your best choice is writing an EAI, as CDAS got deprecated with ISAM 7 and the 3rd option requires an additional software component.
Related
I'm attempting to setup a resource server that hosts resources that require different levels of security.
Through a web application I want to authenticate the users, by specifying the lowest Authentication Context Reference (e.g. basic email/password authentication). This provides an acr value for the session to the resource server. User can then access basic functions of the resource server.
If user wants to access resources of higher security, the resource server should redirect user to authorization server. This redirect should specify a higher ACR.
Within the authorization server, this new value ACR would trigger another authnetication flow including MFA.
The user would then reauthenticate with higher security and therefore obtain access to the requested resource on the resource server that required that higher security.
How can this scenario be achieved?
I do not see anywhere in Spring Security how to easily specify ACR values, or even to trigger re-authnetication of the user.
Checked many many website regarding step-up authentication, adaptive authentication, acr values, etc...
I 'm trying to create a secure spring rest api using pre-authentication security for siteminder.
I 've tried a solution where I 'm getting SM_USER and when I tested it in postman by adding new header SM_USER with random value it seems to work fine.
If you don't provide header I'm getting an error org.springframework.security.web.authentication.preauth.PreAuthenticatedCredentialsNotFoundException: SM_USER header not found in request which is valid.
But how can I be sure that this is secure? if someone knows the URL of my rest api could call this without problem. Should I check something else in spring or only siteminder offers user authentication?
The front-end SiteMinder web agent is the guaranty that the session is valid - you must make sure via server/network configuration that your application cannot be accessed directly without first passing through the SiteMinder web agent.
Also, SiteMinder asserts multiple headers. SM_USER should not be used alone because it can be asserted by the web agent in some circumstances when the user does not actually have a valid session. Instead, you should first look for the existence (non-blank) of SM_SERVERSESSIONID, which only exists if the session is valid.
Lastly, I generally try to avoid SM_USER at all - because SM_USER is actually not a user attribute at all, but rather is "the login identifier used for authentication". If SiteMinder authenticates users via federation (e.g. SAML) or x509 authentication, SM_USER will be rather different than if a login form was used. Instead, its better in SiteMinder to set a "universal id" that is a user attribute, and appears in the headers as SM_UNIVERSALID. Your SiteMinder administrators will know how to do this (and may already have - look to see if you have a SM_UNIVERSALID header available already).
One other caution, in some SiteMinder configurations, the underscore will not be in the header name (use of the underscore is called "legacy" header mode in SiteMinder), so you might want to make your app configurable with respect to the header names, e.g. SMSERVERSESSIONID, SMUSER, SMUNIVERSALID etc.
If you want to programmatically re-validate a session, you can use the SiteMinder Agent API or REST API, or look at my company's product "SSO/Rest" which provides a comprehensive set of uniform REST interfaces to SiteMinder and also other SSO providers (http://www.idfconnect.com).
HTH!
-Richard
TL;DR
Objective: managing api permissions:
OIDC authorization direct grant flow
User federation and authentication source : LDAP
Permissions store : legacy database
Client management and authentication: Keycloak
Question: What are the best practices for managing user permissions on Keycloak and rest api?
Context
We are implementing a rest API with spring to be used by a mobile application and an SPA. Our users accounts, permissions, rules… and all data are stored in a custom database used by different monolithic applications. To secure our api we have decided to use Keycloak.
The keycloak server is configured with an existing LDAP for user federation and ‘Direct grand flow’ for the mobile client application. For the first use case (authentication) everything is working fine.
Now we have to manage users permissions as follow :
The client applications should know user permissions to display/hide functionalities
The api should be able to validate user permissions to use different endpoints
Users permissions are based on some rules in the database and change frequently
In my understanding keycloak can handle authorization and fine grained permissions using hardcoded or user based policies but can’t be plugged to a different authorization source natively. As a consequence, I thought of building a custom role mapper using Keycloak SPI, retrieve user permissions from a custom api that I will develop, then map them to the access token.
As a result, my access token should look like:
"resource_access": {
“My-client”: {
“permissions”: [
“Show-products”,
“Buy-something”,
“Display-prices”
]
}
},
"username": “myUser”
Then the mobile application should be able to know user permissions based on the token, and my stateless server side (API) should be able to access user permissions on every call to check them using spring annotation :
#PreAuthorize("hasRole('Show-products')")
Problem
After first experimenting my solution seem to work fine, but I still have some security concerns about this choice since it’s out of the keycloak standard and includes rest calls to a different backend inside keycloak mappers.
So I was wondering :
Is it secure to put user permissions on the access token claims?
How to secure keycloak access to an external system (rest calls) to
retrieve permissions?
Should I rely on token claims to verify user permissions on each
request in my resource server?
Is there any other clean solution / best practices to handle user
permissions from external source in keycloak ?
Complimentary Informations
I’m using :
Springboot 1.5.13.RELEASE
Keycloak-adapter-bom 3.4.3.Final
Standalone keycloak server 3.4.3.Final
regarding your questions:
- Is it secure to put user permissions on the access token claims?
Yes, capabilities can (and should be) on the access-token, and with that you can take some decisions in your business layer (based on the roles/access claims). Remember nevertheless that a token is only base 64 encoded, and could be copied by other person and looked into, so it shouldn't contain secret or particularly confidential information, usually you put there enough info regarding the user, and some of its current permissions/capabilities/claims.
How to secure keycloak access to an external system (rest calls) to retrieve permissions?
It depends if it needs to be accessed from outside your network. If not, you can leave it unprotected (and unavailbale from outside/or only available for some specific IPs). If it is going to be available from outside/or you want to protect it with keycloack anyway, you can have either a "confidential" or a "bearer only" type of client. I'd suggest you to look into CORS and token sharing, so that you can reuse your already created "access-token" for your other endpoints without the need to authenticate again.
Should I rely on token claims to verify user permissions on each request in my resource server?
Not exactly sure what you mean. In keycloak the resource server isn't doing extra resource authorization like in a typical oAuth2 dance (unless your policy enforcer is activated but I believe you didn't go with this approach, but rather a mapper SPI #auth server for getting your roles right?)
In oAuth2 the "resource server" has 2 responsibilities: 1-providing the resource and 2-doing an extra authorization step. In the keycloak world those 2 steps are done by different actors. Step 1 is done by your application, and step2 is only done when policy enforcing is activated by keycloak also (that means Keycloak is the auth server and also part of the "resource server" from the oAuth2 perspective)
Now back to your question, if by resource server you just meant your application providing the content, then yes you can use the claims there, remember that the claims (and the whole access-token) was generated and digitaly-signed by the auth server, so you can use those claims in your app with no problem (and wouldn't know how to do it otherwise either).
Is there any other clean solution / best practices to handle user permissions from external source in keycloak ?
Hard to say, as you probably noticed; documentation in the web for your specific usecase is very limited; so not a lot of work of best practices exist there, you only real alternative would have been using policies with a custom Policy SPI, and that would have brought in other challenges. I'd say your solution is fine.
Best regards.
I have a need to authenticate against Azure Active Directory from a .net Web API. I read Vittorio Bertucci's article: Using ADAL .NET to Authenticate Users via Username/Password, and was wondering if there's any way of getting around the limitation of not being able to do this from a website/confidential client. He describes this as an AAD setting. Is it one that can be turned off?
Any assistance with this would be much appreciated!
This is not common scenario to use the Resource Owner Password Credentials in a web app. The recommend way is that using the Client Credential flow as Shawn Tabrizi suggested.
If you do want to use the Resource Owner Password Credentials flow, you can construct the request yourself as below:
POST: https://login.microsoftonline.com/xxxxx.onmicrosoft.com/oauth2/token
Content-Type: application/x-www-form-urlencoded
resource={resource}&client_id={clientId}&grant_type=password&username={userName}&password={password}&scope=openid&client_secret={clientSecret}
The Client Credential Flow (App Only Flow) should enable your confidential client to be able to authenticate to a downstream resource without a logged in user. This type of authentication is pure Service to Service Authentication, and will require only a secret for the client app to be presented either in the form of an App Key (symmetric key) or a Certificate Credential (asymmetric key).
However, all forms of access to an AAD Resource will require some form of initial interactive login. In the case of App Only Flows, you will need an Admin to perform an interactive login experience with the Client application, which will then allow subsequent user-less flows.
Check out these sample and let me know if it addresses your question!
https://github.com/azure-samples?utf8=%E2%9C%93&query=daemon
I hope this helps!
I am starting a new project where we are planing to build a restful back end and an AJAX font end. I am approaching the problem by focusing on Identifying all the resources that I have and what the various HTTP verbs will do them, their URI and the JSON representations of those resources.
I am looking for the best design for securing the backend. Here is the list of designs I have considered. I am looking for alternative designs not listed below, and pros, cons recommendations. The system will be implemented with Spring 3.0 and possibly Spring Security 3.0, SSL will be used for many parts of the system but not for all of them, so some requests may come on SSL and some might not.
Option 1: Use the HTTP session
Show a standard login screen, create a server side session and let tomcat send back a jsessionid cookie and have the ajax client include the JSESSIONID cookie on every XHR request. This options just feels like it's the wrong approach for the following reasons.
The connection becomes statefull which is against the rules of REST
I want to be able to split the bakcend into multiple seperate WAR files which means i could have multiple HTTP sessions on the backend, if that is the case then this approach does not work. While I don't need the ability to split the backend into multiple apps today, I would prefer a design that allows for that possibility.
Option 2: Find an open source Java based security library that does this
Other than Spring security I have not found any other Java libraries, any recommendations are highly appreciated.
Option 3: Try to use an existing protocol like OAuth
In my very brief look at OAuth it seems that it is designed for authentication across sites where each site has it's own user database. In this system i want a global user database shared across all the backend ajax services.
Option 4: Use SAML and Shiboleth
This options seems over kill and hugely complex to setup and maintain.
Option 5: Send the username and password with every request
This requires that user sends their username and password with every request, which means that the front end AJAX app must store the username and password as a JavaScript object and if the user navigates away from the page then back the username/password combo will be gone and the user might be forced to log in again. I don't want the front end to try and put the username and password into cookie as that would comprise security.
Option 6: Implement my own authentication / Authorization protocol
Create a REST service that users can present their username/password combination to and then get back and security token, which they must send back to the service with every request. The security token would be digitally signed by the service and would have an expiry time. The token would be only good for most operations high security operations would require a new login screen as port of confirming the operation.
Problem with this approach is I have to invent yet another security protocol which seems like a total waste of time.
I am sure I am not the only person up against this problem, I hope the stack overflow community can point to some options and tools that I have not found yet.
Take a look at Apache Shiro. It is an authentication system that has a session management feature that can be used to share sessions across applications. This may be the easiest thing to do.
Or you could use Spring Security (or Shiro) with a Remember Me cookie that is shared across the webapps (as long as they are in the same HTTP domain). The remember me cookie would be analogous to your token in option 6. You can set the expiration on the cookie that so it is short lived like a session cookie or long lived like a regular remember me.
You might also want to take a look at Jasig CAS - Single Sign-On for the Web. It has a REST API and a protocol (Proxy Tickets) that allows services to proxy user AuthN to backend services like you described in option 6. http://www.jasig.org/cas
Briefly...the application that serves up the AJAX client is protected with Spring Security (supports CAS out of the box) and gets a Proxy Granting Ticket that you embed in the AJAX client. The AJAX client uses the PGT to get Proxy Tickets for your REST services...protected with Spring Security too. The REST services get an authenticated userId without every touching primary credentials.
Alternative, you could keep the PGT on the server and use AJAX calls to retrieve Proxy Tickets that are then used by the AJAX client to call you REST services.
As I understood you are going to secure a rest application, to preface you must know that a security provider consisd of three concepts (3A):
-Authentication
-Authorization
-Auditing
to implement these three together you must provide bunch of tools such as :
-SSO provider
-Session Store
-Open Id pattern
-user credentials integration
....
I have used ACL(Spring ACL) to provide authorization services and oauth2 for authentication.
there is one channel to connect these two together and its scopes(oauth2 scopes) but the problem is scopes are not flexible(pure strings) enough to implement authorization modules such as role_voter, cache_strategy, black_list or,Role_base strategy, exceptional permissions, white_list... (but you can use #EnableGlobalMethodSecurity)
In my case I used authorization server as a resource for oauth2 authentication server(take a look at http://projects.spring.io/spring-security-oauth/docs/oauth2.html), then I considered two spots to check authorization, the first I issued ACL to front-end and forced programmer to design her page dynamically up to ACL concept, the second is in back-end on service layer(BLL) using Aspect when one rest is going to be called. I sent the service key as an actee to check if current user has enough access control to do that. and for auditing you must monitor all requests I mean you must use an listener in your gateway or broker...