I am using Shibboleth IDPv3.3 to integrate with our SP and I was able to get the SSO authentication with LDAP working.
However I am seeing the NameID which is a generated one and not the one I entered during authentication
<saml2:NameID Format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
NameQualifier="https://shib.nslab.com/idp/shibboleth"
SPNameQualifier="https://chandracppm.nslab.com/networkservices/saml2/sp"
>7DBQ2seeNYvP9l6RsCrJZRh8/kw=</saml2:NameID>
For our SP we want the actual username that the user entered in the login page to be returned as the NameID.
What is the configuration I need to do to achieve this.
I was able to get the Shibboleth IDP v3.3 to return the username entered as NameID in the SAML response by doing the following
In the attribute-resolver.conf
<AttributeDefinition id="uid" xsi:type="PrincipalName">
<AttributeEncoder xsi:type="SAML1String" name="urn:mace:dir:attribute-def:uid" encodeType="false" />
<AttributeEncoder xsi:type="SAML2String" name="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent" friendlyName="uid" encodeType="false" />
</AttributeDefinition>
in the SP Metadata specifying the NameID format
<NameIDFormat>urn:oasis:names:tc:SAML:2.0:nameid-format:persistent</NameIDFormat>
In the saml-nameid.xml
Commenting out all other beans except
<util:list id="shibboleth.SAML2NameIDGenerators">
<bean parent="shibboleth.SAML2AttributeSourcedGenerator"
p:format="urn:oasis:names:tc:SAML:2.0:nameid-format:persistent"
p:attributeSourceIds="#{ {'uid'} }" />
With these 3 pieces of configuration and making sure that attribute-filter is set to release all the attributes I was able to populate the UserID entered by the user in the Shibboleth IDP as the in the response assertion.
Related
I added support for SAML 2.0 SSO with Okta to my application using Kentor AuthServices .NET package and the first action done by a user is clicking "Login with Okta" button and then being redirected to Okta's sign in page with SAML request token generated by Kentor.
In some scenarios the user email (username in Okta) is already known beforehand and I want to pre-populate the Username textbox on Okta's sign in page with this value.
Is it possible to do that, for example by providing the desired username in SAML request or in the cookies?
The SAML standard has support for including a Subject (that is a user name in SAML lingo) in the AuthnRequest. Unfortunately Kentor.AuthServices doesn't support that (yet). There has been some work done (see https://github.com/KentorIT/authservices/issues/430) but I don't know the current status.
Then you of course need to check whether Okta supports reading that data.
Can anyone tell me how to pass RelayState for an IDP initiated SSO connection. We have the SSO working but would like to deep link to a page within the service provider's application. They have instructed us on the RelayState to pass but I can't figure out how to format the URL for Okta. We are using the app embedded link and would like to append RelayState to the query string.
For IdP initiated SSO (where you login to IdP first, then access SP), you can modify the RelayState under General SAML settings, like:
Note the app embed url is for IdP initiated SSO only, it shouldn't be used for SP initiated SSO as its IdP SSO URL.
When user accesses SP directly (without login to IdP first), it starts a SP initiated SSO. That's where you can append the ?RelayState=your_deep_link to the IdP SSO URL, so that after you login on IdP, it returns the deep link back to SP for you to redirect to.
And like #Thomas Kirk said, "you can find the IdP SSO URL url by clicking "View Setup Instructions" on the Sign On tab for the application in the admin console."
To start IdP initiated SAML with Okta you need to use the IdP SSO URL with ?RelayState= appended to the url, not the app embed url.
You can find the IdP SSO URL url by clicking "View Setup Instructions" on the Sign On tab for the application in the admin console.
An example (don't forget to URL encode the query string):
https://thomas-kirk.oktapreview.com/app/salesforce/kqk5e18ZGRXWPQXOCNBQ/sso/saml?RelayState=%2F_ui%2Fcore%2Fchatter%2Fui%2FChatterPage
Currently, I'm using spring-security-saml2-sample project(V1.0.1) as an SP, and Shibboleth as an IdP. I've implemented the Web SSO profile and trying to write an ECP client to make ECP profile work. However, I found limited documents about ECP profile in spring security saml(Ref doc Chapter 10.4)..
I found two useful ECP client samples in github:
github.com/spaetow/ShibbolethECPAuthClient
github.com/DARIAH-DE/shib-http-client
After enabling PAOS binding and "ecpEnabled" in SP's metadata generator, I wrote some sample ECP client code refering to the above two project, the main flow is:
Send a Get request to "localhost:8080/spring-security-saml2-sample/saml/login" with PAOS related header.
Get the response(SAML Request) and generate a SAML Envelope.
Use the new generated SAML Envelope to Post to Shibboleth IdP(https://exampleIDP/idp/profile/SAML2/SOAP/ECP), with UserName/Password in Authorization Header(basic authentication).
Shibboleth authenticate and response with SAML Assertion(Also an SAML Envelope).
Send the SAML Assertion(Envelope) to SP: "localhost:8080/spring-security-saml2-sample/saml/SSO" and get response.
I think I've succeeded in the first four steps, Shibboleth can authenticate the user and send the SAML Response. But I've got some problems in the 5th step. And even some examples end in step 4.
I found that, spring security saml gets the 5th request and tries to Authenticate the SAML response just like WebSSO profile does. The logic is in "org.springframework.security.saml.SAMLProcessingFilter". After parse the saml response and get the Authentication, the response will be redirect to a default target URL"/". The logic is in AbstractAuthenticationTargetUrlRequestHandler.handle(req,resp,authn). So, I can only get an 302 HTTP response in the ECP client.
Here are my questions:
I want to get user information in the 5th step, do I have to write another filter instead of "SAMLProcessingFilter" to send the Authentication as response? Or is there any other ways(I think ECP client cannot parse SAML Assertion received in Step 4)?
In this situation, my ECP client likes "Rest client" very much, because I have not record any cookies in my code. So after the 5th step(after login), how can I access the SP again for another resource? Does that mean I have to record the JSessionID cookie in the ECP client?
Is the theory of SAML SSO(WebSSO) like Jasig CAS(Use cookie/session)? If so, in the ECP mode, How can I single sign on two ECP clients(each connect to different SP but SP cpnnect to the same IdP). Or, can I make SSO in a ECP client and a browser?
Thanks in advance!
i have a little question.
At the moment my Spring configuration uses the DefaultTokenServices (provided by the spring-security-oauth2-2.0.0.M3.jar).
It generates correctly the access_token.
Now what i will do is to cancel/delete/remove/revoke this token when i do a logout.
In the security.xml i configured the logout in the http tag:
<sec:logout logout-url="/logout" logout-success-url="/auth" invalidate-session="true" delete-cookies="true" />
and the redirection is successfully. But if i write a test doing a login, logout and after i try to access a restricted path with this access_token i can get a successful request, but i expect a Not authorized Error.
Why?
How can i configure the logout that the access_token are automatically deleted to force an new login?
The lifetime of the access_token is independent of the login session of a user who grants access to a client. OAuth2 has no concept of a user login or logout, or a session, so the fact that you expect a logout to revoke a token, would seem to indicate that you're misunderstanding how OAuth2 works. You should probably clarify in your question why you want things to work this way and why you need OAuth.
If you really want this behaviour, then you would have to code it yourself (in a custom Spring Security LogoutHandler, for example), but the lifetime of a token is normally governed by its expiry time. Token revocation would usually be a separate interface provided to the user, allowing them to prematurely revoke access to their resources for one or more clients - something like Twitter's third-party applications access.
At the end I followed this
link
And in the LogoutHandlerFilter i call the TokenService.revokeToken() method.
I am using Spring Security 3.1.x and trying to achieve the following scenario:
a page is secured with isFullyAuthenticated()
the current user is only authenticated with Remember Me, so not fully authenticated
the user navigates to this fully authenticated page - this should not be permitted (and it's not)
however, the user should not get the 403 page - instead, the user should be prompted to login via the Login form
after logging in, the user should be allowed to proceed to the page he previously requested, since now he's a fully authenticated user
My Spring Security config is:
<http use-expressions="true">
<intercept-url pattern="/admin/full_auth_only.html" access="isFullyAuthenticated()" />
<form-login login-page="/login.html" default-target-url="/authenticated.html" />
<logout />
<remember-me key="someAppKey" />
</http>
And I tried to add:
<access-denied-handler error-page="/login.html" />
However, the problem is now that, when visiting the page, I am indeed prompted by the Login form, only the URL doesn't correspond to login; instead it's the URL of the fully authenticated page:
http://localhost:8080/spring-security/admin/full_auth_only.html
Which then breaks the authentication process, which fails when trying to access the (invalid) URL:
http://localhost:8080/spring-security/admin/j_spring_security_check
This should have been:
http://localhost:8080/spring-security/j_spring_security_check
Any help on this is appreciated - I think the usecase is very common and so I would prefer using the namespace support instead of going in a custom direction.
Thanks.
Eugen.
I couldn't reproduce your issue with version 3.1.3.RELEASE of Spring Security. Which version do you use?
Authentication requests are intercepted by the AbstractAuthenticationProcessingFilter that checks if the URL of the request ends with a pre-configured value (that defaults to /j_spring_security_check). Any URL with that ending will trigger an authentication attempt. You can see the related code here.
This means that the URL you said is invalid should in fact be processed without problems.
The code linked above hasn't been changed since very early versions (2.x), so there should be some other issues in your case.
If you could share your configuration and some debug level logs, that would help to reveal what's the real problem.
1.Remove any welcome-file-list if you have in web.xml.
2.Make sure always-use-default-target is not set to false in form-login tag or remove it all together.
3.And make sure you have permitted every one to access your login page. something like this <intercept-url pattern="/login.htm" access="permitAll()"/>
That should work.
it sounds like the cookie was not set, and the following requests sent were all treated as the first requests without a session ID, so spring security asked for login every time even though you had logged in.
If you were using google chrome, and tested the application in your local machine using the localhost address, the cookie might not be set. And it is a known issue with Google chrome.
You can try 127.0.0.1 instead to test. Or try another web browser like Internet Explorer.