lamx6 (lamx6) asked a question.
Hello,
Our company uses AWS IAM, with Okta used as a SAML identity provider.
For that, we have multiple Okta apps with https://company.okta.com/ prefix.
So the task is to obtain valid set of temporary STS credentials, using Okta user login, with password and MFA verification.
okta-auth-dotnet (https://github.com/okta/okta-auth-dotnet) provides APIs for user authentication and MFA verification. The process produces (one-time?) SessionToken.
Using it to get SAML assertion, though, is not that clear.
Browsing examples in the Internet (like this: https://github.com/oktadev/okta-aws-cli-assume-role/blob/6247cf870b8c68de1ea4fca1b8b67706a48624b3/src/main/java/com/okta/tools/saml/OktaSaml.java*L115), one can suggest that using HTTP GET with ?onetimetoken=<SessionToken> query parameter is a valid method to retrieve SAML (from a hidden input field value on returned page?). Although not explicitly documented.
Is it correct, or is there a different (official) way to retrieve/parse SAML, having SessionToken available?
Thank you,
Oleg
Hello Oleg,
Unfortunately, we don't have an official/documented way to retrieve a SessionToken from a SAML assertion.
However any other methods that you find, are valid to retrieve the information that you need.
Hi Andony,
Sorry, but my question was about the opposite - how to use SessionToken to retrieve SAML assertion.
Invoking Okta App page and pulling SAML from a hidden input element does work, but presents unintended consequences.
Let me ask one more question then, if you don't mind.
What is SessionToken expiration time, and how Okta Admin can control it?
Successful Authentication Response, returned as a result of user authentication and MFA verification, includes some ExpiresAt field:
09:40:49.756 AuthenticationResponse [5]
09:40:49.758 .AuthenticationStatus: SUCCESS
09:40:49.761 .ExpiresAt: 5/10/2021 13:45:48 +00:00 => 0.00:04:58
09:40:49.763 .RelayState:
09:40:49.766 .SessionToken: 2011...Sn4F
09:40:49.769 .StateToken:
What exactly expires in 5 minutes? Not SessionToken, for sure - it can be reused over and over again.
So the questions, again, are:
Thanks,
Oleg
Hi Oleg,
Thank you for the clarification. At the moment we don't have a way to collect a SAML assertion by using a Session Token. The most efficient way to get a SAML assertion is by using a SAML Tracer extension in a browser.
The session token expiration times that can be controlled by Okta are handled by the sign-on policies, keep in mind that these session tokens are issued when a user logs in to Okta.
In terms of a session token for a SAML application, that is handled on the application side, as we are only authenticating their request not controlling the application session.
The timer that expires in 5 minutes is for the SAML authentication request. If the request is not authenticated within 5 minutes, then the session expires. That time will be different depending on the applications.
Thank you, Andony.
It is still not clear - what the authentication response expiration means.
The auth response cited above brings the client a session token. Which (at least, with default Okta settings) can be reused, seemingly, forever. On one of my client instances, I am able to pull new valid SAML, and use it to get fresh temporary AWS IAM credentials every hour - for 8 days straight and running...
Thus the question - what exactly needs to be set on Okta Admin side to prevent (officially - "one time") session token from being reused?
How come this is not configured by default to a sensitive value?
Hello Oleg,
The response timer is the time set by the IDP for the response to be delivered to the application, in other words, the SAML response needs to get to the application within 5 minutes otherwise, the authentication will fail.
As mentioned before the session tokens of a SAML application is not controlled by Okta. An application like AWS IAM can control the length of time that a user can be signed in to an AWS account. But a STS session is controlled by the application not by Okta. Not every Application in Okta will have a functionality like this, because Okta does not have control over the session tokens sent by the application.
The session tokens that you can control are only for users logging into Okta, which have a default timer of 2 hours, but it can be changed in the sign-on policies.
No, I'm not talking about STS or SAML expiration - these are clear.
The session token returned as a result of Okta authentication and MFA verification - that's my concern.
It looks like this token can be reused forever.
I can issue GET requests to an Okta App like this:
GET https://mycompany.okta.com/xxxxx/yyy/?onetimetoken=<SessionToken-from OktaAuth>
reusing the same one and only session token,
and receive fresh sessions with valid SAMLs
Does not look right to me
The session tokens from Okta authentication are controlled by your sign-on Policies in your Okta admin dashboard go to Security > Authentication > Sign-On > Add or modify the rule of a sign-on policy, at the very end there is a setting called "Session expires after", that setting controls the session tokens issued by Okta authentication.
Thanks. Let me pass this to our admins
Good Morning
In Web UI, you have a checkbox to control session (?) duration:
and it works as designed.
But it looks like the expiration is checked on the client side (Web page) only?
Consider my logs snapshot:
13:54:54.755 User e007754 authenticated: MFA_REQUIRED -> 5/13/2021 17:59:54 +00:00
13:54:55.572 [ChallengeMFA] MFA Factor selected: push/OKTA
13:54:56.059 [ChallengeMFA] MFA [push]: auth status: MFA_CHALLENGE
13:54:56.881 [VerifySecondFactor] MFA Factor selected: push/OKTA
…
13:55:01.829 [VerifySecondFactor] MFA [push]: auth status: SUCCESS
13:55:02.645 ShowBalloon(Downloading SAML...)
13:55:02.672 AuthenticationResponse [5]
13:55:02.674 .AuthenticationStatus: SUCCESS
13:55:02.677 .ExpiresAt: 5/13/2021 18:00:01 +00:00 => 0.00:04:58
13:55:02.680 .RelayState:
13:55:02.683 .SessionToken: 20111…buYc3jp4x
13:55:02.685 .StateToken:
13:55:02.693 Cookies (before):
13:55:02.695 JSESSIONID=07E8B073027F6D01DCB89A44231FDC18
GET(SessionToken) -> SAML
13:55:03.780 Cookies (after):
13:55:03.782 JSESSIONID=31AE171EB1783683FF7A7B27AA085D20
07:55:59.129 ShowBalloon(Downloading SAML...)
07:55:59.148 AuthenticationResponse [5]
07:55:59.150 .AuthenticationStatus: SUCCESS
07:55:59.152 .ExpiresAt: 5/13/2021 18:00:01 +00:00 => expired: -0.17:55:58
07:55:59.153 .RelayState:
07:55:59.155 .SessionToken: 20111L…TbuYc3jp4x
07:55:59.156 .StateToken:
07:55:59.162 Cookies (before):
07:55:59.163 JSESSIONID=D412...26A
GET(SessionToken) -> SAML
07:56:00.366 Cookies (after):
07:56:00.368 JSESSIONID=026BC48...0DFD
It looks like Okta does not validate session token expiration on the server side?
Hello Oleg,
That checkbox is only for the MFA part, not for the actual SAML authentication.