I have a webapplication using spring security. I'd like to login using an account i have configured on the WSO2 identity server using OpenID.
I can login just fine, the identity server asks for the password and redirects me back to my webapplication. So far, so good. However, when i try to request additional attributes using the attribute-exchange, i get empty values.
I have tried a few different types:
schemas.xmlsoap.org/ws/2005/05/identity/claims/givenname
axschema.org/namePerson/first
urn:scim:schemas:core:1.0:name.givenName
schema.openid.net/2007/05/claims/nickname
wso2.org/claims/givenname
But none of them seem to yield any results.
Am i missing something obvious?
The reason may be the fields are empty as well.
Can you try with the following claim URI, http://wso2.org/claims/role. By default all users have the everyone role. So that value should be returned.
Related
We have implemented Spring Oauth authorization+resource server that can be used for external applications.
Now we would like to add custom checks before some oauth calls returns in the authorization server, most importantly for the authorization code but also before allowing returning a token sometimes.
An example use case might be that which users that are allowed to login for a specific client_id might vary and if not allowed this should generate a redirect back with an error.
So for example a user might trigger a login from a third-party app, redirected to our authorization server and shown a login page, however after login it is discovered (through our business logic) that this specific user is not allowed to authorize access to that specific app/client id.
What is the best way to achive this result in a way that is consistent error handling in Spring oauth?
Also, a related question is also how to resolve the client details before the login screen shown so more specific client details can be shown when logging in?
We could parse the client_id parameter manually but maybe there is a more elegant way to hook into Spring oauth to solve this?
(sorry for dual question but its sort of related and the first question is the most important one)
I have configured a .NET MVC application to authenticate against a separately running Identity Server (IdentityServer3). I have configured OpenIdConnectAuthenticationNotifications.SecurityTokenValidate() to place the user's claims into the AuthenticationTicket. Everything seems to be working as expected. The first time I access a page in the MVC app I get the Log In screen and after logging in I am redirected to the requested page.
But, when I look at the HttpContext.User (using a breakpoint in my override of CheckAccessAsync()) it has 2 identities. Looking closer I can see that both identities are the same, and that accessing the Claims property returns all of the claims twice.
Any ideas what I might be doing wrong?
I believe I have figured out what this issue is. I had configured the Authentication Server and the MVC app to use the same client, which actually caused other problems.
When I changed the Authentication Server to use its own client, the HttpContext.User in the MVC app still has 2 Identities but the Claims collection are not duplicated. I'm guessing that the Claims collection only contain the claims for the client that is accessing the collection. But I be totally sure since both clients return the same Claims collections.
I have searched enough but I haven't got a clear answer and thus posting this question.
I have an existing application which uses spring security for authentication.
Current implementation uses a custom implementation of UsernamePasswordAuthenticationFilter for doing this.
Thus the flow is something like below(in very simple terms):
inputrequest>DelegatingFilterProxy>LoginUrlAuthenticationEntryPoint>CustomUsernamePasswordAuthenticationFilter>AuthenticationManager>CustomAuthenticationProvider
Now I have a requirement to implement SSO (since the user is already asusmed to be authenticated) in some scenarios.
The requirement states that if I have a specific request parameter present then I need to automatically authenticate the request without bothering about user/password.
So it is same set of resources and I do not have to authenticate user/password if the specific SSO related request parameter is present.
e.g
suppose a resource \test\bus is a secure resource.
if I come from normal way then we need to check if the user is authenticated or nor and force user to put valid user/password
if I come from SSO channel then I need to show the \test\bus resource as the user is already authenticated.
currently all the access restrictions are put through <http> element
e.g the snippet of security-config.xml is as follows:
Query: What options do I have in this case. I can think of below options:
Pre-authenticate the user before spring security framework kicks in. This will mean creating an authentication token and putting in spring context before spring security filter is called. This can be done through another filter which is called before spring security filter chain. I have tested it and it works.
Create another custom security filter which set-up the authentication token. I am not clear if this is correct approach as not sure when do we create multiple custom security filter
Create another custom authentication provider e.g SSOCustomAuthenticationProvider. This provider will be called in the existing current flow as we can have multiple authentication providers to a authentication manager. The only issue is that in order to achieve this I have to change the request url to authentication filter's target url so that spring security doesn't check for authentication.
to explain more,
let's say request uri is /test/bus, I will write a filter which will intercept the request and change it to /test/startlogin. This is currently my CustomUsernamePasswordAuthenticationFilter's target url i.e
<property name="filterProcessesUrl" value="/test/startlogin"/>
The flow will be
inputrequest>DelegatingFilterProxy>LoginUrlAuthenticationEntryPoint>CustomUsernamePasswordAuthenticationFilter>AuthenticationManager>SSOCustomAuthenticationProvider
I have tested this and this works. Is this a valid approach or a hack.
Is there any other viable option available with me.
Thanks for reading this.
Can I make a Single Logout from WSO2 Identity Server using POST not Redirect?
I keep getting the following message:
No established Sessions corresponding to the Session Indexes provided
After some debugging I found out that the session index is obtained by a corresponding sessionID. This session ID is obtained from a cookie named samlssoTOkenId. The thing is that when I am sending a POST to the Identity Provider, I do not have this cookie - I can set it up manually but I do not know its value.
My questions are:
Is this appraoch even possible - using POST not REDIRECT?
Is there some configuration on the Identity Provider which will search for the session index in the request itself not using the cookie approach?
Is it possible to somehow obtain the value of this session ID - when receiving the response after authentication or some other means?
Thanks in advance!
With WSO2IS 4.5.0 and latest versions SessionIndex attribute is returned with the SAML2 Response. Here, You need to enable the Enable Single Logout when service provider is registered in WSO2IS. Also all Single logout requests are handled with respect to the SessionIndex attribute not with the "samlssoTOkenId". As i understood it is invalid to use the cookie values as SessionIndex. But there is no way to configure POST and Redirect. I guess currently it is only supported for Post. Please find the more details about single logout implementation from here. This blog is true with the WSO2IS as well
I'm implementing and OpenId Provider based on the DotNetOpenAuth OpenIdProviderMVC sample. From the RP, I'm creating an OpenIdRelyingParty, and calling CreateRequest with
http://localhost:PORT/User/xrds
This correctly redirects to the OP, and everything seems to work, but the ClaimedIdentifier that comes back is always
http://localhost:PORT/User/xrds
even when I'm expecting
http://localhost:PORT/user/username
where username is the user I logged in with. Is this an issue with the sample, am I using an incorrect URL as the UserSuppliedIdentifier, or is it something else?
Try to define a different URL as UserSuppliedIdentifier. For instance, use something like http://localhost:PORT/Discovery that executes an action returning the XRDS file. And for identity discovery, define a route to redirect http://localhost:PORT/user/username to a action Identity serving the XRDS file for identity verification.
That worked for me.
Good luck.