I am using Wso2 SAML for authentication and XACML for authorization. After wso2 authentication, how to revoke the SAML token and generate a new token?
how to revoke the SAML token and generate a new token
Reading the question it invokes me an idea, that there is an attempt to treat the SAML Assertions similar as the JWT token (hold and use until expires, revoke or request a new one). Please don't do that. I've seen multiple developers even succeeding with builing a system that passes the SAML assertions along the other API requests. It is possible, but not intended and not always feasible. SAML Assertions document can be large, specifically when encrypting the assertions.
SAML Assertions (see, I deliberately do not use word token not to be mistaken) are a one-time certificate where the issuer (IdP) asserts information about the subject. There is no direct backend connection between IdP and SP (there is no token service, this is an intended feature of SAML) and all needed information are passed in the Assertions. Then it is necessary to prevent the replay attack, so the lifetime of the SAM assertions is usually short only to allow some clock skew between the IdP and SP (5-15 minutes). It is writte somewhere i the SAML specs
The client can/needs to establish its own use of the information in the assertion (e. g. session cookie, own jwt token, whatever) . SAML doesn't prescribe its use, only mandatory validation steps. WSO2IS offers an SAML Bearer OAuth2 profile to swap the SAML Assertion for the JWT token.
But I am having to doubt how to refresh the assertion after certain period(I mean expiry period).
Disclaimer - I never used that profile. Based on the documentation the client could remember the assertion id and request the current / extended subject attributes (like a userinfo service for SAML). As comes from my experience, it's better to pass all required information in the original SAML assertion and not to use any very volatile attributes as an identity attribute.
Related
In wso2 IS 5.10 I have a claim skype which is a local claim which I am returning from saml assertion as a attribute. But using SAML grant type if I generate OAuth2 token by exchanging SAML Assertion I am not getting claim skype in jwt token as claims.
I have added a skype claim in openidscope as a external scope also and also I have added skype claim as requested claim in service provider.But then also in jwt token claim is not returning.
Seems you are checking the requested claims on the JWT access token requested using the saml-bearer grant.
Self Contained access token in saml-bearer grant won't return the user claims is a known issue tracked in;
https://github.com/wso2/product-is/issues/6321 and
https://github.com/wso2/product-is/issues/12131
You should be able to retrieve the claim values in the id token as mentioned in the above issue descriptions.
I have a doubt regarding the jwt token validation done by the REST api and was not able to find a simple yes/no answer. Assume that everything is being transferred over HTTPS.
I have the following setup
React app
REST API
AWS Cognito that handles the user registration/login
When a user wants to login, then the React app would call the AWS Cognito api and validate the credentials. If valid, Cognito will send back a jwt token (that will contain the necessary meta data) that can be passed to the REST API. Now I see two options
the backend verifies that the jwt token was not altered using the rfc spec. If valid, the api extracts the necessary meta data and continues to process the request
The backend verifies the validity of the jwt token, but also calls the Cognito service to verify the metadata in the token.
I think that since everything is handled over HTTPS and the fact that its hard create a valid token then the first point is enough. There is no need to have an extra call over the wire. Am I wrong ?
Found the following question from softwareengineering.stackexchange.com which pretty much answers my question. Link
The local validation of the JWT token is enough when the token was created with asymmetric encryption.
I am using the following doc by AWS for verifying the incoming token with Cognito to verify the user in cognito pool:
https://docs.aws.amazon.com/cognito/latest/developerguide/amazon-cognito-user-pools-using-tokens-verifying-a-jwt.html
Now I also need to verify one of the custom attributes (email) of that user. (Basically this is to mitigate a case where some user can change their email-id in the API payload to access someone else's details).
The Cognito SDK I found to do this was this : https://docs.aws.amazon.com/cognito-user-identity-pools/latest/APIReference/API_GetUser.html
It works just fine, however this led me to a question :
Since I'm sending access token in this SDK, do I need to use the former jwt-based token verification as well? Because this SDK also handles the case where token is invalid/expired and sends error codes accordingly. Is there something I'm missing which the former case handles and the latter one doesn't ?
Short answer: no, you can ignore the contents of the JWT.
Longer answer: JWT tokens provide a fast way to verify that a user has been authenticated, without the need to check a database or external service. This can be very important in a high-volume application.
However, they have several limitations:
A JWT token is issued with an expiration timestamp. If you rely on the JWT, you do not have a way to forcibly log-out a user until that timestamp expires.
To be secure, your JWT token must be signed using an asymmetric keypair (I mention this simply because a lot of people have implemented their own identity servers incorrectly; Cognito does it right).
The claims that are in the token (and are signed by the identity server) may not be sufficient for your needs. Best practice is to minimize the size of the token, and iirc Cognito follows this practice by only including the user attributes that are directly tied to authentication.
If any of these limitations apply to a particular use-case (and it sounds like the third applies to you), then you'll have to make that external service call to the identity server. And if you do that, and the server reports authentication status, then there's no need to pay attention to the token.
community.
I'm using WSO2 IS 5.7.0 to integrate an Angular app with an external IDP.
The external IDP is configured with SAML2 and the service provider Inbound Authentication is set with Oauth/OpenID.
The service provider uses Federated Authentication to comunicate with the IDP.
The user uid from the IDP is matched with the claim userid, so when I ask for an oauth token, I get the correct scopes (matching a local user with roles configured) to use the token with WSO2 AM. This is working well whe I get the initial oauth token using code grant.
If I introspect this token, I can verify the token belongs to the username XXXXXXXX and the scopes are the ones to consume an API on WSO2 AM, based on the roles associated to the local user XXXXXXXX.
The problem is when the refresh token is used to get a new access token after expiration. The new access token comes with the same scopes, but I cannot consume the same API I was consuming with the first token. I get a 403 Forbidden on every call and the AM log shows:
WARN - APIAuthenticationHandler API authentication failure due to Invalid Credentials
(The first WARN appears only once)
WARN - APIAuthenticationHandler API authentication failure due to The access token does not allow you to access the requested resource
(this WARN appears on the subsequent calls)
If I introspect the receibed token, I can see the same scopes as the original access token, but the username is different:
FEDERATED/XXXXXXXX#carbon.super.
I think this username change on the token information leads to the 403 error.
The problem is worst if I activate the Service Provider option "Use tenant domain in local subject identifier" on the Local & Outbound Authentication Configuration. In this case, every time I ask for a new token with refresh token, the tenant is appended to the username on an infinite loop:
XXXXXXXX#carbon.super#carbon.super#carbon.super#carbon.super
On every token I get, the introspect shows me another #carbon.super is appended to the username of the actual token. In this case, the FEDERATED/ is not always present on the username.
I expect the username associated to the refreshtoken to be equal to the one on the first access token.
Is there a configuration to solve this or this is a bug? is resolved on new releases of WSO2 IS?
(sorry for my english)
Thanks!
Similar issue is reported[1] and fixed with PR[2].
[1] https://github.com/wso2/product-is/issues/4472
[2] https://github.com/wso2-extensions/identity-inbound-auth-oauth/pull/1022
If you don't have a WSO2 subscription, upgrading to the 5.8.0 will resolve the issue.
I'm considering securing a whole Java EE software platform with OpenAM (prev. Sun OpenSSO). Applications - running on WebLogic AS - would be secured by a JEE Policy Agent and web services with WS-Security SAML Token Profile.
As of my understanding, the SSOTokenManager enables application code to retrieve OpenAM's SSO token. But in order to invoke the SAML protected Web Services, I need to obtain a SAML Assertion from OpenAM. Can anybody tell me how to do so ?
Also, in the Web Service code, I may need to get back a SSO Token from a SAML assertion. Is that possible ?
You should be able to achieve both conversions using OpenSSO's Security Token Service. There is a tutorial for configuring it.
The SSOToken is an internal OpenAM representation of a users session, whilst a SAML token is an asserted identity with associated information. As such, these are not directly translatable in the way you describe.
In order to obtain a SAML token for use in your web service call, you should look at the STS functionality in OpenAM. The is a standardised service that will authenticate users and then make an assertion about the identity and authentication of the user, represented by a SAML token. This token is then returned to the calling entity (the web service client) who can include this token as per the relevant WS-* standards.
You may also want to look at the OpenAM wss provider or the Metro/WSIT library to assist implementation on the client side.