I am using kerberos/spnego authentication with spring security to authenticate users from Active directory services, client is windows 7. I have a concern with the kerberos ticket renewal process. I understand the ticket is valid for 10 hrs, what will happen when a user launches and application which uses kerboros ticket and the ticket present on his machine has expired, will the browser automatically request a new ticket to the AD server or the authentication fail?
No, he won't be able to request a service ticket anyway. It is highly likely that Windows will prompt for your password again. You cannot request new service tickets with an expired TGT.
Related
I have a bunch of legacy MVC apps that are using a custom forms authentication provider. The cookies are being saved under *.companydomain.com and all api's and identity server should have access to these cookies.
We are rolling out identity server for new apps. We would like to give the legacy applications access to some of the new api's and we want the tokens to be under the users session.
Is it possible to have IdentityServer's silent login read the legacy cookie and build out a new session without the user having to do anything?
EDIT - So I guess the workflow would be.
User visits website and logs into legacy SSO.
Website sends legacy cookie to Identity Server to login and obtain access token.
Identity Server uses cookie to lookup auth from legacy SSO. Does not require any user interaction and finishes authentication flow.
If for some reason cookie is invalid or expired, Identity Server just 401's instead of redirecting to login.
Website can now provide access token when accessing newer api's.
Lets say i have 5 applications and I have a common auth server.
My applications redirect the page to auth server for the first time, gets back a JWT token and then allows the user to use the application further.
Now the user is ready to use the application, but the application's backend has no clue on whether the token is still valid or expired. So Am I supposed to make a validation call to my auth server every time an API in my application is called before processing the request? Is it not adding additional overhead (multiple hops) and impacts the response time of the application?
Is it possible for the application to check the validity of the token by itself without making a network call to the auth server? What are the best practices an application developer should follow while using an auth server for SSO?
Is it possible for the application to check the validity of the token by itself without making a network call to the auth server?
Expiration: Include en exp claim into the token with the expiration date. Any client can decode the token and check the date
Signature: The client can verify the signature of the token to check if it comes from the expected server and trust the contained data. Then you would need to use an assymmetric keypair (e.g RSA)
What are the best practices an application developer should follow while using an auth server for SSO?
This question is opinion-based and is off-topic in StackOverflow. Could you be more specific about your doubts or include a programming issue?
Is SSO an overhead?
No, your application is clear example of why a SSO system is needed:
SSO: 5 apps ->1 user login
Without SSO: 5 apps -> 5 user logins
OAuth2 client secrets/keys in Azure AD are issued for 1 and 2 years. This means that approximately in a year our secrets/keys will expire. We're very worried that that will break the "refresh token" step and our service will stop working for hundreds of our active users who have authorized Yoxel to access their Office 365 accounts. This is a huge problem for us as many of our clients are enterprise users that don’t want to be bothered with requests for re-authorizations. Our service runs in background and they pretty much forget that it exists.
Could you please comment on this topic? Is there a way for us to ensure that our existing users for whom we have OAuth2 access/refresh tokens now won't have to re-authorize Yoxel to access their accounts again when we generate a new secret/key for our client-id?
Thank you.
Please read here to learn a ton more about Azure Active Directory's Configurable Token Lifetime.
If you check out the section on confidential clients you will see the following:
Token lifetimes with confidential client refresh tokens
Confidential clients are applications that can securely store a client
password (secret). They can prove that requests are coming from the
client application and not from a malicious actor. For example, a web
app is a confidential client because it can store a client secret on
the web server. It is not exposed. Because these flows are more
secure, the default lifetimes of refresh tokens issued to these flows
is until-revoked, cannot be changed by using policy, and will not be
revoked on voluntary password resets.
So the token you generated will continue to work, independent of the lifetime of the secret used to originally generate it, and as long as the access/refresh token is valid.
Can someone shed some light on the use case for me. We wave users who will be signing in to third party client applications. Using OAUTH2 framework, the client app will redirect to our site to authenticate. From my undestanding, the Authorization server will return a access token and an id_token (OpenID Connect).
1) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go back into the client application hours later, do they still have go through the whole redirect to our /authorization endpoint to re-authenticate?
2) If the user is authenticated with us and is redirected to the client application, if they leave the client application and go to our site, do they have to login again to authenticate?
Basically, does OpenID Connect over OAUTH2 allow a user to sign in once and then not have to sign in again after subsequent visit to the third party app or our app?
Thanks.
It depends on two things:
a. if the client application maintains a session and that session has not expired yet, the user won't be redirected at all
b. in case the client session timed out, the user will be redirected but if the IDP still has an authentication session running, the user will not have to authenticate and will be sent back immediately to the client app with a new token.
It depends on the IDP session existence/timeout again
Essentially an Identity Provider authenticates users and decides how to do that. It can prompt for credentials but can also create and maintain authentication sessions for the user for (typically) a limited period of time which allows for true Single Sign On (SSO).
Also note that this behaviour does not depend on the exact protocol at hand (OpenID Connect, OAuth or even SAML): it would work the same for any protocol that redirects a user to an Identity Provider in a federated SSO system.
In OpenID Connect, the session at RP typically starts when the RP validates End-User's ID Token. ID token consists of expiration time. So if the user just leaves (not logged out) and the id_token is expired when he access the RP, then the end-user needs to re-authenticate.
If the end-user logged out from the relying party and the OpenID provider supported logout mechanisms such as OIDC session management, OIDC front-channel logout or OIDC back-channel logout, then all RPs sharing the same browser session will be logged out (SLO). Then the end-user needs to login to the OP again to access the RPs.
I have an MVC application that connects to CRM via the SDK's OrganizationService. The user logs in via a form in the application using their username and password. The CRM organization uses claims-based authentication and is connected to an ADFS 2.0 server.
Whenever I try to authenticate a user via their username and password, the newly instantiated service reuses an earlier token it got from successfully connecting. This makes it possible for users to log back in with just the correct username - even with an invalid password. The connection I'm using is set to have an instanceMode of PerInstance and that doesn't appear to help either.
I feel like I'm missing something essential here. Do I have to do something to tell CRM to re-authenticate my users' credentials or do I have to do something to tell our STS server to invalidate the previously issued token?
Thanks.
Your MVC application should not connect to CRM with the credentials of its users. Instead you should use the credentials of the service account of your MVC application (i.e. the application pool identity).
Of course the service account must be a user of the CRM Organization and (in CRM) this user account should be allowed to impersonate other users.
When your MVC application needs to access CRM on behalf of a specific user, it creates/gets an OrganizationServiceProxy instance (which can be reused) and sets its CallerId property to the systemuserid of the impersonated user.