I can't find security details that are covering SCIM protocol.
In SCIM documentation there is only in paragraph 4 :
Authorization and authentication must be guaranteed for the SCIM
operations.
When I set REST API (for SCIM) on well known address (according with SCIM protocol) how to control then access ? Everyone can sent SCIM filter request and get response with all resources ?
SCIM leaves this aspect to the implementation providers, cause there already many types of mechanisms
to secure a web resource.
Related
I'm new to security and I'm trying to understand how to implement proper security without any overkill.
Below are my questions.
I don't want to allow 3rd party clients to use my API and hence I don't see any importance of OAuth 2.0. Hence I'm looking to use the sessions generated by keycloak (or Ory Kratos) in my Spring Boot Security. Any guidance on how to do that.
I have come across an application https://opstra.definedge.com/ which security is implemented using keycloak (can see the URL pattern). But in the requests, I can't see any JWT token in the chrome DevTools Network Tab while performing any network requests. I think they are implementing it the way I wanted. Any overview on how it is implemented.
I'm not architect at definedge, but I'm pretty sure they do not use Keycloak sessions in Opstra (they would have to run Opstra inside Keycloak servlet for that). It more looks like they use OAuth2 to authenticate users from a Java client and that this client has sessions of its own enabled (JSESSIONID cookie for opstra.definedge.com VS sso.definedge.com). It is quite possible that this java client uses access-tokens to authorize requests to resource-server(s), we just can't see it from the browser.
Restricting the clients allowed to consume your API has little to do with authorization method:
with basic authorization header, any client with login and password can access
with Bearer authorization header, any client with a valid token can access (which you already had anticipated)
even JSESSIONID cookie can be set for any origin (I believe), in which condition any request from the same browser would be authorized, whatever the web client.
Restricting your API clients is more about CORS configuration, which aims at just that: filtering which origins (host + port) can access which resource location (URL)
There is a notion of confidential client in Keycloak where the client must provide a password in addition to client-id to exchange authorization codes for access-tokens, but this does not apply to rich clients (clients running on devices you cannot trust): Angular, Vue, React, native mobile apps, etc. code can be reversed enginereed to read that password. But it is possible to configure a Java client of your own as "confidential" and as so, allow this client only to get access tokens to query resource-server (API).
OAuth2 comes with much more than just easing multi-client scenarios and JWTs with session-less java applications greatly ease horizontal scalability and fault tolerance. You should read this article for a refresher on
OAuth2 (and its value)
resource-server security configuration (with CORS)
I need to develop set of microservices (rest APIs) which is to be used by web and mobile client, the microservices are sitting behind API gateway, I've to integrate with SSO (using SAML) for user's authentication, I understand that SAML token to oAuth2 token conversion has to be done so that I can verify auth token at API gateway and handle authorization there itself, but the piece which is not clear to me is that who will take care of conversion of SAML token to oAuth2 token, is it IDP who provide this functionality out of box or do I need to built up something of my own?
One possible solution which I'm thinking of is
User (from web/mobile) sign in via SSO
Gets SAML response from IDP
Send that SAML response to server to generate Auth Token
Server gets request to generate auth token, looks for SAML response and validate it against IDP
If SAML response is valid then generate auth token and send it back to client
On subsequent API request from client the token is passed as header which API gateway validates
The thing is I'm bit reluctant to implement SAML and oAuth thingy myself and looking for some ready made solution but couldn't find any, can someone please suggest of any library solving this problem, thanks in advance.
It feels like your approach is correct - it is the role of the Authorization Server (AS) to deal with SAML login integration for you. Only configuration changes should be needed, though of course you need to use an AS that supports SAML integration.
Your UIs and APIs will not need to know anything about SAML and will just use OAuth tokens. There should be zero code changes needed.
Most companies use an off the shelf AS - eg from a low cost cloud provider. My Federated Logins Blog Post summarises the process of integrating an IDP. The walkthrough uses AWS Cognito as the AS - and the IDP could be a SAML one.
I maintain a microservice that sounds like it could help you - https://github.com/enterprise-oss/osso
Osso handles SAML configuration against a handful of IDP providers, normalizes payloads, and makes user resources available to you in an oauth 2.0 authorization code grant flow.
Osso mainly acts as an authentication server though - we don't currently have a way for your API gateway to verify an access token is (still) valid, but that would be pretty trivial for us to add, we'd be happy to consider it.
I was reading up about API Gateways (Kong) and I wanted to integrate it into my application. Every tutorial I've seen creates consumers for the services using Kong API or through a dashboard like Konga. I already have a user registration/auth service. How can the API Gateway replace that ? How should the user registration be changed so that Kong knows about it ? And how would login work because In all the examples I've seen the ApiKeys or JWT secrets are created in Kong ? Can any body shed some light on how this works in practice ?
In my opinion Kong is not supposed to replace a user registry / authentication service. However, it can help you enforce authentication.
There are several options of securing your APIs against unauthorized access. These include:
API key: this type is used with the key-auth plugin and is not intended for authenticating users (meaning natural persons) but consumers (meaning other systems).
JWT tokens: this type is used with the jwt plugin and is suitable for user authentication. Kong is responsible for validating the JWT tokens (by checking the signature and expiry of the self contained token). You can of course do further checks either with custom Kong plugins or within your upstream service.
So I think you shouldn't think of Kong as a replacement for your user service, but as a complement/addition which helps you enforcing security policies even before the request reaches your upstream service.
Could anyone explain what would be the best approach for this scenario?: There are 2 separate Service Providers:
System A is a server that works as a rest API for a mobile application.
System B is a website which login is handled with simple and plain cookies.
I have read a lot and Ive found that the most used protocols in use right now for these kind of systems are SAML and OAuth, where OAuth works specially to give security to API services and SAML for web applications (cookie based).
Ideally, what is being looked for is a single log in, which is right now handled for System B through cookies in the main domain.
Is there a way to use both SAML and OAuth? Or What would be a good way to go?
The answer depends on what IDP you currently have.
Is the IDP SAML based or is that just what you got from researching?
SAML and OAuth don't really play well together.
The ideal would be OpenID Connect where you could use the OpenID Connect token to get a REST API token. But that would involve using the same IDP for authentication for both.
It depends, If you have both app deployed on same server then you can use SSO with tomcat valve or JBOSS with picketLink. If your applications deployed on different domain then you need to use federation server with SAML like OpenId, OpenAM, Spring-saml with ADFS or any other IDP server.
For securing rest API, you have to use Oauth protocol. By implementing OAuth you will get Oauth token by providing userId and password. Then Oauth token can be used to access rest API from mobile or any other third party service.
I am trying to implement SAML SSO between two J2ee applications (form-based) deployed on two different instances of WAS, I have configured both WAS instances as service providers using the steps in http://pic.dhe.ibm.com/infocenter/wasinfo/v7r0/index.jsp?topic=%2Fcom.ibm.websphere.nd.multiplatform.doc%2Finfo%2Fae%2Fae%2Ftwbs_enablesamlsso.html
I set the property sso_1.sp.login.error.page to the login page of the Identity provider but when I get redirected to the login page, it displays that no SAML request (AuthRequest) is available, can anyone tell me why the WAS is not issuing the SAML authentication request?
WAS does not send a SAML request in the redirect. This is explained in the paragraph above this section of the DeveloperWorks SAML TAI article. The scenario you're expecting is referred to as the solicited response. WAS only supports what the article terms the unsolicited response. In this latter case, the IDP must understand how to authenticate the user (usually through a browser interaction) without a SAML request.