I need to check if user is authenticated in the system in a PHP application that is not a PHPCas client. Does the RubyCAS server provide API for this? How do you make secure communication in this case?
The solution to the problem is the gateway feature of the CAS protocol. This feature will redirect a user to a CAS server so that the user’s browser can be authenticated via the initial ticket-granting cookie given to it the first time the user submitted credentials. If the ticket-granting cookie is found, then the CAS server will redirect the user back to the app without having to re-enter credentials. Read more at Techslate about this user authentication solution
Related
I have the following scenario that I am curious if it is possible to implement. I need to use SSO and more specifically OneLogin to authenticate the user via custom UI from my Java standalone application. I know this can be done via Create Session Login Token and then Create session via token One Login API calls. With some parsing I can get the session cookie out of the last call and store it.
Now I need to programmatically hit the API server, which is to be build still and this server somehow needs to validate the session cookie that I am going to send along with request. The key word "Programatically" as in there will be no browser
OneLogin doesn't provide SDK to validate existing session cookie => it would be nice if I could, based on session cookie find out if it is still valid and what is the user name used for this session. If session is invalid API server would return unauthorized.
Is this even possible? Or is it possible in some other way?
Basically One Login is already used in our ecosystem and I have to continue using it
The app that will log user in and get the session cookie may not be the one calling the API server. This could be another java application that would receive the session
I guess what I am looking for is Validate Session equivalent from Open ID Connect API in general API
The session_token that is returned via that API has a short expiry is only intended to be used for making the Create Session request which returns session cookies.
It sounds like OpenId Connect might be the best option for this use case. If you have user credentials then you could use the Resource Owner Password Grant flow to authenticate the user and obtain an id_token.
The id_token is a JWT containing user details can then be verified for authenticity by checking its signature, audience and expiry claims. It can also hold other custom information about the user that may be used by your backend application.
We have one intranet Application and implemented ADFS authentication on it. We have our custom login form with Username and password and we are authenticated easily using ADFS. we are using windowsmixed endpoint to authenticate
Application, Users and ADFS all are in one domain
Now we want to skip that login page, so if Domain\User1 is logged in on his/her machine , intranet application should authenticated with current windows logged in user automatically without asking username and password when we open it.
Is it Possible and How?
Thanks!!!
Regards,
Darshit Gajjar
Normally this is done via IWA in a browser (WS-Fed passive profile). IWA is a function of the browser not ADFS.
You are using WCF (WS-Fed active profile) which has no browser component.
I am trying to implement a OAuth2 Provider, that authenticates users with a custom login.
For understanding I looked at the Spring Boot OAuth2 Tutorial.
I don't quite get, how I can implement my own Authentication meachnism to work with the OAuth2 SSO from my Server.
I want to add custom authentication mechanisms (like "user has to answer a question for authentication" or "user has to enter id and click button for authentication") instead of the Facebook and Github examples.
I read about implementing my own AuthenticationProvider, but I am stuck how to combine all the puzzle parts.
Let's go one step at a time. OAuth is only authz provider so not talk about authentication. Now for your usecase specifically, if you want user to be authenticated then OAuth authz code based flow makes sense (You can even go for implicit flow, check rfc 6749). Now how will this work for you. I am picking up the implicit flow for simplicity, Authz flow is just extension of it where end client gets a temporary code which it exchanges with Identity Server later to get the access token. Here are the steps:
Client App hits the /authorization uri with data as per rfc 6749
After validating the submitted data, server forwards user to Login page (or other page for authentication). After authentication, cookie is set in the browser or data is stored in server to mark a user as authenticated.
After authentication server redirects user to user consent page (You can even skip this if needed depending on need, But OAuth 2 spec contains this) where user specifies which all permissions (scopes) are allowed, here user can allow either allow or deny.
if user allows then these permissions are submitted to server and then server stores the data and redirects the user to client URI with access token in # fragement of client redirect URI (callback URI submitted during actual request)
I'm currently building an application that uses Okta for authentication, and I'd like to build a feature that allows users to change their password once they've logged in. Unfortunately, I can't seem to find an endpoint that will serve this purpose. The main change password API, api/v1/authn/credentials/change_password only works for users currently in the PASSWORD_WARN, and PASSWORD_EXPIRED states. Is there any way to use this or another similar endpoint once the user has logged in?
Yes, in this case you'll want to look at the Users API (and specifically the Change Password section).
Generally, the /api/v1/authn/credentials/change_password endpoint that you mentioned in the prompt is strictly for the authn flow - it's the endpoint you use to transition the user from PASSWORD_WARN or PASSWORD_EXPIRED to the next authentication state (by providing a new password).
The /api/v1/users/:id/credentials/change_password endpoint can be called at any time by your backend service, and doesn't strictly require the user to be authenticated - it's not CORS enabled and you'll need to provide an ApiToken when sending a request to it.
When a browser client successfully submits the username/email and password to the server and the next request the client retrives data from the server how is the client identified being successfully authenticated already?
I found this info:
"After the user enters credentials, the browser automatically sends them on subsequent requests to the same domain, for the duration of the session."
From where does the browser take the credentials for each subsequent request?
Do I have to actively save the credentials somewhere? How is the magic happening?
Once the user's credentials have been authenticated by the server, the server returns an authorization token (commonly called auth token which is a long string made up of characters and numbers) which identify that the user has been authenticated and is valid. Every time, the user sends in his request, the request data will also contain this auth token (either as a cookie or added in to the request itself) which lets the server know that the client is valid. Because of this, the request is authenticated each time but not by using the actual username/password credentials.
Based on requirements, the auth token may be set to expire after a certain period (if there is not activity such as in banking applications).