My thinking was that Symfony2 would extend the ExpireAt on each page request made during the authenticated session. So if the timeout was 100 seconds and you made a page request, the new ExpireAt would be time() + 100. This "use it or lose it" authentication functionality is similar to what you get on a banking website.
The default functionality seems to be when the session timeout is set to 100 in the config.yml, the user only has 100 seconds to do what they can.
I don't think this will be to hard to implement but where should it be done? My first guess is in the isEqualTo method. Once you can determine the user is authentic you can re-up their expireAt. Or does the cookie need to be modified?
The answer lies in the refreshUser method of the UserProvider and the isEqualTo method of the UserClass.
The isEqualTo method tells the user provider whether to refreshUser(UserInstance user).
Step1 : isEqualTo() returns false; (as your understanding grow, so can this logic. But essentially, this triggers refreshUser().
In all the basic user provider examples, the refreshUser & loadUserByUsername are identical. The to do what I'm talking about, the refreshUser() needs to be a little different.
Step2 : modify refreshUser(UserInterface $user). What's being passed into this method is the original userClass. So the refreshUser is responsible for syncing the expiresAt or credentialsExpireAt
I use this logic in my refreshUser() to either extend the expiration date OR set it to the original expiration date (which is expired):
if( time() > $user->getCredentialsExpireAt() ){
$refreshedUser->setCredentialsExpireAt( $user->getCredentialsExpireAt() );
}
Related
When a user's password is updated I want the Security stamp value to be updated every time that happens. I believe that is how Security stamp works from my research.
I place this code in the ApplicationUserManager.cs but this isn't working:
private static string NewSecurityStamp()
{
return Guid.NewGuid().ToString();
}
What and where do I need to get the security stamp value to change each time an update is made to the user's account?
That is what happens. However, the security stamp is only re-validated on an interval (every 30 minutes, by default), to reduce the number of database queries being made. You can lower this interval, even to zero, which effectively makes the stamp be re-validated with each request. However, that will increase the chatter back and forth to the database.
services.Configure<SecurityStampValidatorOptions>(o =>
{
// WARNING: this will issue a query for every request
// You might want to rather just compromise with an interval
// less than 30 minutes (5 minutes, 10 minutes, etc.)
o.ValidationInterval = TimeSpan.Zero;
});
An alternative option is to simply log the user out after such a change. If the goal is to simply make them re-login, that should do the trick much better. Just inject SignInManager<TUser>, and then call SignOutAsync on that instance. You'll need to redirect the user afterwards. That could be directly to the sign in page or to some area of the site that is protected, which will then cause them to be taken to the sign in page to authenticate. In either case, a redirect is necessary to have the auth cookie actually be deleted.
I'm trying to wrap my head around Elm. I have experience in Haskell, and a bit of Erlang.
I want to complete the following exercise:
User is shown a login form
On submit, the frontend makes a request to localhost/auth to try and receive an auth token.
On success, the homepage is shown, which fetches some data.
On failure, the login screen displays an error.
This is quite basic, but hopefully complex enough to model the behaviour of a real webapp.
My first problem is with the Model. I only need the data if the client is authenticated. Should I wrap this in something similar to a Maybe monad?
type Model
= NoAuth String String
| AuthFetching
| AuthFailed err
| AuthSuccess String
And then the login screen can display a spinner, and error, or redirect to a new page.
This feels like it ties the rest of the applications state to the authentication state. Although is is "correct", it feels wrong to have the whole model be a (variant type?) with only one record.
It "feels" more correct to have the model like so:
type FetchStatus
= Loading
| Success val
| Err err
type Model =
{ token : RequestStatus String
, data : List number
}
But whenever you update the model, you now need to check if token is still present - i.e. pattern match within the record. In the first example, you only needed to pattern match on the whole model, which is a bit simpler.
And to hold the login form state, I'd need to add extra fields:
type Model =
{ token : RequestStatus String
, data : List number
, username : String
, password : String
}
Which feels incorrect because the password should not be held in memory after login. I'd hold these in records, but I cannot use records in custom type declarations.
All in all, I'm a bit confused. Can someone please shed some light on the most "correct", idiomatic way to do this?
All authorization related stuff should be handled on the backend side. Elm's job is only to display what server has sent to it. In my opinion the first option you proposed is the best for such a little example, but in more real-life application the typesystem would be more complex:
type LoginForm =
{ username : String
, password : String
}
type Activity
= Login LoginForm
| LoginSuccess
| LoginFailure String
type Model =
{ loggedUser : Maybe String
, activity : Activity
, ...
}
You don't need (and shouldn't) keep password on frontend. You also shouldn't perform any authorizations on the client side, as the client may easily replace any script in his browser. The backend will track whether the user is logged in by eg. session cookies. In this scenario even if the loggedUser value is set to Just "someguy" and "someguy" is not marked as logged in the server database, any action that requires authorization shall fail.
Summarizing, handling login and giving permissions to access any content is a job for backend. Elm is frontend language, so it's only purpose here is to display things.
I have figured out that to use OneLogin Protect with saml assertions, you need to call the SAML verify factor without the OTP provided, and read about a similar question here, but if I simply put this in a loop with a sleep, the User is bombarded with OTP calls, until they hit "Accept". If the user takes 10-20 seconds to pull their phone out, and I sleep for 20 seconds, that means that users who have their phone immediatly available and could response in 2-3 seconds, have to wait 20 seconds to cover the slower calls.
To adress this, I would like to check the saml assertion verify without sending a push notification, and just the state_token.
I have also noticed that if I were not to use SAML assertions, I could do this as described here: https://developers.onelogin.com/api-docs/1/multi-factor-authentication/overview but that requires me to give either Manage users or Manage All permissions to the API keys. As this is a Python cli utility to handle aws saml auth, and one way or another, we need to distribute those API keys to users, this seems like excessive privileges for a user to log into AWS.
Does anyone know how can I check the status of an OTP for OneLogin Protect with SAMl assertions, without creating a new OTP call every time I check the status?
Example code
ol_client = OneLoginClient(
'client_id',
'client_secret',
'us',
)
saml_resp = ol_client.get_saml_assertion(
'ol_username',
'ol_password',
'aws_app_id',
'subdomain'
)
call_result =ol_client.get_saml_assertion_verifying(
'onelogin_aws_app_id',
device.id,
saml_resp.mfa.state_token
)
if call_result is None:
verify_result = None
while verify_result is None:
sleep(1)
verify_result =ol_client.get_saml_assertion_verifying(
'aws_app_id',
device.id,
saml_resp.mfa.state_token
)
I've found an answer by now. Just forgot to update:
The API exposes a Message field in the verifyFactor endpoint. While it's pending for the user to act on it, it will contain the string pending.
rMfa, err = c.VerifyFactor(token, &pMfa)
for strings.Contains(rMfa.Message, "pending") && timeout > 0 {
time.Sleep(time.Duration(MFAInterval) * time.Second)
rMfa, err = c.VerifyFactor(token, &pMfa)
if err != nil {
s.Stop()
return nil, err
}
timeout -= MFAInterval
}
I resorted to check every second until the timeout expired. The full implementation can be seen here: https://github.com/allcloud-io/clisso/blob/master/onelogin/get.go#L133
I defined a security check adapter and configured the property which is shown below.
<securityCheckDefinition name="MySecurityTest" class="com.sample.MyTest">
<property name="successStateExpirationSec" defaultValue="30" description="How long is a successful state valid for (seconds)"/>
</securityCheckDefinition>
The configuration means that when I pass the security check, I can access the protected resource under the scope for 30 seconds.
After 30 seconds, the server will force client to logout.
However, no user want their app repeatedly doing validation with high frequency.
We know we can increase the value of successStateExpirationSec, unfortunately, it cannot meet our requirement.
How can I extend the property "successStateExpirationSec" before the time
expired and without revalidation ?
It is not recommended to update the "SuccessStateExpirationSecond" after setting it and before it expires. I think Logical approach for your usecase is to determine the proper value "SuccessExpirationSecond" and set the properties to that value.
Instead of updating in the SecurityCheckDefinition in adapter.xml, you can also set it programatically by Extending "CredentialValidationSecurityCheck" .
Refer sample here .This allows you to set the default properties value.
I was surprised I couldn't find a good answer to this out on the interwebz, so here we are.
I'm setting a FormsAuthenticationTicket to expire after a week. This is used in tandem with a "Remember Me" setting we feature on our login form. This is being accomplished by :
var cookie = new HttpCookie(FormsAuthentication.FormsCookieName);
// set the auth token expiration to a week
var authTicket = new FormsAuthenticationTicket(1, user.Email, DateTime.Now, DateTime.Now.AddHours(168), true, userData);
var encryptedTicket = FormsAuthentication.Encrypt(authTicket);
cookie.Value = encryptedTicket;
cookie.Expires = authTicket.Expiration;
With this, I've also extended our session timeout, as many of our users keep the application open for equally long periods of time :
<forms loginUrl="~/account/sign-in" timeout="10080" name="t5S4U4Y152" domain=".xxxxxxx.xxx.xxxxx"/>
My question :
I've been asked to make this a non-expiring cookie, such that as long as the user retains it, they'll always be logged in - more or less an infinite login. Is there a default value I can set the ticket and timeout to in order to achieve this?
Yes, I could set both expiration's to something like 50 years from the present, but I'm wondering if there is a cleaner or more suitable approach?
No there isn't any value you can set the expiration so it is infinite. You'll just need to set it to something really long.
As you know, if you do not set an expiration the cookie then only lives for the length of the session (when the browser is closed), which is definitely not what you want.
You can also use slidingexpiration=true so that whenever a user comes back to the site, the expiration date on the cookie is refreshed to be Today + Timeout instead of DateInitiallyIssued + Timeout