Caching/Storing the LTPA token generated in datapower - ibm-datapower

I'm generating an LTPA token in datapower after the authentication.
I want to store this token for further processing.(to validate against another request)
How can I store/cache this token in datapower?

If you are on firmware 7.2 or 7.5 you can write to file system using GatewayScript or you can store it in a system variable (set-system-var) but I would advice against that!
Another option might be if you are using IBM MQ to store it as a topic.

Related

How to securely store OAuth 2.0 credentials in Firebase?

So I'm using Firebase functions to connect with an API that uses OAuth 2.0 and I need a secure place to store sensitive credentials (the refresh token). However, the token needs to be generated on the fly, so I can't store it in an environment variable.
Where is the most secure place to store sensitive credentials in Firebase?
Thank you!
I typically keep such credentials in memory after it's been generated. That means that future invocations on the same container will use the same credentials, while on a new container my code will generate new credentials.

IdentityServer Access Token is short in length

I implemented the Identity Server using the stores against CosmosDb, the access token is very short compared to the id token, guess I'm missing some config or some interface to implement.
Access Token: -TPc90IVKUxMOxLLIZmQcCgGGkdRXf7207sfb_b1-7E
Id Token: eyJhbGciOiJSUzI1NiIsImtpZCI6InNOcnBNMlVrUEF0ajlZYzZFZGNaVWciLCJ0eXAiOiJKV1QifQ.eyJuYmYiOjE1ODQ5MDMyMjgsImV4cCI6MTU4NDkwMzUyOCwiaXNzIjoiaHR0cHM6Ly9sb2NhbGhvc3Q6NjAwMSIsImF1ZCI6Im12Y0NvZGVGbG93Q2xpZW50Iiwibm9uY2UiOiI2MzcyMDUwMDAyMDQyODgxNzQuWmpjMU9HSTVOVEF0WWpKbVpTMDBNMlJsTFRnelkyTXRaRFZoWmpSbFpUSXpZVEppWWpSa01tWTNZemd0TW1Nell5MDBabUk1TFRrMU9UTXRaamMyTTJRek1XTXpNbVF6IiwiaWF0IjoxNTg0OTAzMjI3LCJhdF9oYXNoIjoiWUM4OU1TTnVmZTVycEpZby14Y3l1QSIsInNfaGFzaCI6IkcwUmM0eDktTHRJN0pFZUdxQmtUN1EiLCJzaWQiOiJ0a3IwNGVNOG1UVS02dG96anNqTEdBIiwic3ViIjoic3VkaGVyc29uLnZAZ21haWwuY29tIiwiYXV0aF90aW1lIjoxNTg0OTAyNjYzLCJpZHAiOiJsb2NhbCIsImlkIjoiYjQ0YjRhMWItOGU1NS00OGUzLThkZjktYWUxNzhmZThkY2ZjIiwibmFtZSI6IlN1ZGhlcnNvbiBWZXRyaWNoZWx2YW4iLCJnaXZlbl9uYW1lIjoiU3VkaGVyc29uIiwiZmFtaWx5X25hbWUiOiJWZXRyaWNoZWx2YW4iLCJlbWFpbCI6InN1ZGhlcnNvbi52QGdtYWlsLmNvbSIsImFtciI6WyJwd2QiXX0.N9Xv7Uvgg5GlrB-9HPU3-WJffdP1z_400Rm2f246DPWEM7tDkBOtCUW_1Oo5GXURNgCJXmsQGvKelGUs8ysPzHS_t3faK-_57QHugubUqvDPqJgimHw8iJz-PFNKPS9hPI0Bnw889tNYJ7pnmTQH16PurF2Cgi2xB7p2Uc4SN1HLK5ed3usoMQ4Sxu08ONcy4MFy1b5JDjttSq4EA4xZGunQFNUNxOziroE6VTuvn7aOsEIKIiRuOyKOKQBct_H68Px3FUgwzTZ5ABD52_SzdzqoP1gZEZavSI6Wl5xIlRvaZqEyCUoGZ2TqFKSydRdZbARmSbFl1SfmAzyCwvYjHA
Just for summary:
The issue is solved by using reference token instead of JWT. Id Server 4 is writing grants to storage as reference token by default.
More details for reference token of identityserver4 ,please refer to https://identityserver4.readthedocs.io/en/latest/topics/reference_tokens.html
I started implementing IdentityServer4 against cosmosdb as persistence, referenceLink, had some error while writing grants to cosmos db, then I followed the cosmosGrantStore which helped in fixing this error.
However, the Identity server by default generates reference tokens which are shorter compared to jwt. While use Asp Net Identity Server, jwt tokens were generated, hence the confusion. Later, this useReferenceTokenForApiAuth helped me to use the reference token to authorize Api against the identity server.

How to generate open token?

How to generate open token with the help of agent_config file that will get from ping federate?
I have received agent_config file from ping federate and I am trying to generate open token.
The only supported method for OpenToken generation is by using a PingFederate Integration Kit from Ping Identity. If you are not a customer holding a PingFederate license, you are not licensed to use these kits, and must integrate via a standard of some sort, like SAML or OAuth.
Agent agent = new Agent("agent-config.txt");
Map userInfo = new HashMap();
userInfo.put(Agent.TOKEN_SUBJECT, "username");
String openToken=agent.writeToken(userInfo);

AD FS client authentication from a web-api app. How to?

Given user credentials (i.e. username, password), I'd like to authenticate the user from within our web-api applictation.
I'm considering using a class derived from Attribute and IAuthenticationFilter. The class will use HttpClient to connect to an AD FS server, submit user credentials and retrieve resulting tokens. Selected methods within ApiController(s) will be decorated with the above attribute.
Will the above work?
What is a uri format that needs to be sent to the ADFS server?
Does the http request sent to the server need a body/payload?
What is a response format from the server in case of success (with token)/failure?
I'd appreciate any examples and pointers to on-line docs.
Thanks.
OK - with 3.0 refer to this. You use OWIN and ADAL.
4.0 has full OpenID Connect / OAuth support. You use OWIN and ADAL. Refer here.

PingFederate Parse SAML Assertion

I'm trying to understand the basic flow of an IdP-initiated SSO from a developer's point of view. I am also trying to trace this flow from the sample application provided together with the .NET Integration Kit.
Based on this link:
http://documentation.pingidentity.com/display/PF610/OpenToken+Adapter+Configuration
The PingFederate SP server parses the SAML assertion and passes the user attributes to the OpenToken SP Adapter. The Adapter encrypts the data internally and generates an OpenToken.
Question: How does the PingFederate server parse the SAML assertion? Do I have to code it from the SP server? Or will the set-up of the PingFederate server do the parsing?
What I know for now is that I need to develop the part that parses the OpenToken that is returned by the PingFederate server.
Found this video that provided answer to my questions.
https://ping.force.com/Support/PingIdentityVideoLibrary?id=1011570451001
It turns out that no coding is needed for the PingFederate server, we just have to configure it both for the IdP and the SP side so that they can communicate.

Resources