Develop Reference

Spring Authorization Server. What's the difference between RegistredClient and UserDetails?

On their Getting started guide, reference, Spring Authorization Server have a piece of code where they declare two beans - UserDetailsService and RegistredClientRepository. I wanted to play around retrieving some tokens from the server. I tried using postman. Within authorization tab I entered the values from the guide:
it answered with:
So then I tried inputting client credentials from RegistredClientRepository entry:
And it worked.
So my question is: what is the purpose of UserDetails and RegistredClient being both available in this case?
And another little bit off-topic question: if I create my own authorization server for client credentials flow between my servers, how does every server know that token belongs to legitimate server and not to some attacker who can just register with needed clientId if there's an opportunity? How can resource server actually verify that token owner is the server it trusts?

Generally in oauth2, a "client" is an application which users might use to interface with some service - for example something like an App people can install on their phones or a web application.
Most oauth2 implementations have "scopes" (basically defined sets of access rights). Clients (client applications) are registered with some metadata (name, author, ...), a set of scopes they might use and some details to improve security - like "where is that application hosted" (in form of "which redirect URIs are valid"), client ID and client secret.
Depending on the oauth2 flow chosen, your App needs to prove being that app by some means - e.g. by having a valid combination of client ID and redirect URI or by doing HTTP basic auth with their client ID as username and client secret as password when exchanging a "code" for a "token".
All this was about clients - now about users: they are what you would expect, the users of a service - like you and me are users on Stackoverflow.com
And another little bit off-topic question: if I create my own
authorization server for client credentials flow between my servers,
how does every server know that token belongs to legitimate server and
not to some attacker who can just register with needed clientId if
there's an opportunity? How can resource server actually verify that
token owner is the server it trusts?
for this you could either use a form of signed tokens (look at e.g. JWT) or store the currently valid tokens per user in a database reachable by all your servers - both have pro's and con's, tokens in a database are easier to revoke, while signed tokens don't require you to store any state in a database (which can be expensive in big distributed systems)
Update - OP actually wants to do server-to-server authentication, see comments below
Server-to-server authentication can often work very well without any extra authentication server, in cases where your parties a less dynamic - like when you always have "those three servers" and they don't come and go very often.
In such cases, using a simple token is probably better and easier than using an oauth2 stack. Each server could just have a list of randomly generated strings in its config file, let's call this "the set of valid tokens" and also knows which token to send when communicating with a specific other server. When a request comes in, the server checks if the given token is in its set of valid tokens - done.

Websphere 9, how to check incoming ltpatoken2

Good day
I have an incoming request to my application based on websphere 9 with ltpatoken2 cookie.
Previously, the ltpa key was exported from my websphere and add to another server. The option Application security was enabled.
How I can check, at websphere or at my application, that the token is exists and correct?
And my application should be not avialable for requests without token.

In WebSphere 9, if request contains a LTPA cookie, LTPA cookie will be processed automatically. Inside your application code, if you call API com.ibm.websphere.security.auth.WSSubject.getRunAsSubject(), you will see a subject created form the ltpa token if LTPA token is presented and is also valid.
And you will see unauthenticated subject if ltpa is missing or invalid. Or inside your application, if you call HttpServletRequest.getPrincipal().getName(), you will see a user name represented by the LTPA cookie if it presents and valid, and you will see principal name or see unauthenticated user name if LTPA is missing or invalid.

There's no API to inspect that token, but you can test it implicitly. You can capture browser traffic with Firefox or Chrome developer tools, then after successful login, using either the browser tools or curl, send a modified request without the cookie, or with a bad cookie value, and you should get an authentication challenge since the cookie's not there.

The easiest would be to just add security constraints to your web.xml protecting whole application (you will find many examples), and map security role to All authenticated. Then your application will be available only, if user is already logged in (so the LTPA token exists and is correct), otherwise it will redirect you to login page that you can include in your application and redirect user somewhere, informed that he is not logged in, or whatever you want to do in case there is no valid LTPA token.

How do I get the current user from within an AWS AppStream?

I'm prototyping deployment of an application via AWS AppStream. Access to the stream is managed via a web portal (using SAML). My application needs to know the identity of the user. I could prompt them but I don't want to make them login to both the portal and the application. I want to get the credentials they supplied at the portal. (AppStream instances run under the "PhotonUser" account, so I can't get the username from the OS.)
The AWS SDK has a Session class which contains the user ID but I can't find a way to get an instance of it for the current streaming session.

Have the portal pass a token identifying the user into the AppStream as session context. The token can be anything you want (subject to an unenforced 1024 byte limit) but should probably include a timestamp so that it can be expired and a signature to ensure that it hasn't been forged or tampered with.
Modify your portal to create a custom URL for each user via the CreateStreamingURL API to supply the token as session context. The application in your AppStream will see the session context a command-line argument. Parse and validate the token (i.e. check it for expiration and verify the signature).

AppStream_UserName environment variable is set in each and every session.
So your portal should grab their email address and use this with CreateStreamingURLRequest(plus stack, fleet etc). The portal should now redirect their browser session to this URL.
In that running instance AppStream_UserName will be their email address.

IDP Initiated SSO Implementation in existing App

I have an existing application and all of a sudden i have been given a task to implement IDP initiated SSO. there is a URL to IDP clicking on it asks me to login with IDP provided credentials, after success login the route moves to our application and than my task start to identify the user and give the proper access. I have the certificate provided from our IDP. How can i achieve this? My application is a Spring MVC Java Application.I am using JBOSS AS 7. I havent done a similar thing before. Can anyone please give a step by step clear picture on this? I saw the Spring SAML extension which i couldnt understand properly to get it integrate with my existing app. Any help in this regard will be highly appreciated.

IdP-Initiated SSO
IdP-Initiated SSO with POST Binding
If the user does not have a valid local security context at the IdP, at some point the user will be challenged to supply their credentials to the IdP site, idp.example.org.
The user provides valid credentials and a local logon security context is created for the user at the IdP.
The user selects a menu option or link on the IdP to request access to an SP web site, sp.example.com. This causes the IdP's Single Sign-On Service to be called.
The Single Sign-On Service builds a SAML assertion representing the user's logon security context. Since a POST binding is going to be used, the assertion is digitally signed before it is placed within a SAML message. The message is then placed within an HTML FORM as a hidden form control named SAMLResponse. (If the convention for identifying a specific application resource at the SP is supported at the IdP and SP, the resource URL at the SP is also encoded into the form using a hidden form control named RelayState.) The Single Sign-On Service sends the HTML form back to the browser in the HTTP response. For ease-of-use purposes, the HTML FORM typically will contain script code that will automatically post the form to the destination site.
The browser, due either to a user action or execution of an “auto-submit” script, issues an HTTP POST request to send the form to the SP's Assertion Consumer Service. The service provider's Assertion Consumer Service obtains the message from the HTML FORM for processing. The digital signature on the SAML assertion must first be validated and then the assertion contents are processed in order to create a local logon security context for the user at the SP. Once this completes, the SP retrieves the RelayState data (if any) to determine the desired application resource URL and sends an HTTP redirect response to the browser directing it to access the requested resource (not shown).
An access check is made to establish whether the user has the correct authorization to access the resource. If the access check passes, the resource is then returned to the browser.
See saml-tech-overview-2.0
So if you are implementing the SP, you have to follow the steps 5 and 6 otherwise 1 - 4.
For the implementation you could use OpenSaml if you do not get it working with the Spring SAML extension.

SAML2.0 SSO with the WSO2 Identity Server?

I need to use WSO2 Identity server with SAML for SSO for my internal application. I came across this beautiful
SAML2.0 SSO with the WSO2 Identity Server article
But i have two questions on this article which i am not sure how works
1) In 5th step it is said "Now the user is being redirected to IDP again. Now the IDP realize this user is already authenticated hence it would issue
a SAML Assertion without prompting any authentication challenge."
How will the IDP realize that user is already authenticated ?
As per my understanding it must be done based on session. Does it mean when authentication request goes from service provider 1 to Identity server (SP1 redirects the request to IS thru browser ), IS will first authenticate the credentials and if successful keep the user object under session.
Now when second authentication request goes to IS thru SP2, same session ID is sent (provided request is sent from another of same browser), IS fins already a user object associated with this session, so trust him. Is this understanding correct?
2)In step 2 it is said that " Now the SP1 can validate the SAML Assertion issued by IDP and let the user log-in. "
what is the specific field/value (under SAML response sent by IP) , SP1 will verify?
3) Where user credentials are stored. Is it on IS side or Service provider side?

Just explain how it works with WSO2IS 5.0.0
When user is authenticated to IDP by providing credentials. WSO2IS creates an authenticated session for user and cookie with is associated with the authenticated session set in to the user's browser. Cookie name would be commonAuthId. you can also find it in your browser once you are authenticated with WSO2IS using SSO. Then user is trying to access another SP using same browser, cookie would be sent in to the WSO2IS and it identifies that there is an authenticated session related to the cookie.
Usually, SP validates the SAML2 Response and Assertion. There are several validations that you can do. But most common would be
Signature of the SAML2 Response and SAML2 Assertion
Validity period SAML2 Response and SAML2 Assertion.
Audience restriction validation in SAML2 Assertion
Destination url and Recipient value
Normally Username would be extracted from the Subject identifier value. Also there may be attributes in the attribute statement, which SP can retrieve and do some validation over them as well.
End users are authenticated to the IDP. So credentials must be in IDP not with the SP. It is one of idea of SSO. Maintains the credentials in one place. WSO2IS is default shipped with LDAP based user store. Therefore end user credentials are stored in the LDAP server. However WSO2IS can be deployed with any existing user stores that you like