I am creating a web application compliant with SCIM 2.0. I can create and update users using provisioning, but deleting users always fails.
So, I tried a number of things to resolve my issue, and I found that the "SCIM Provisioner with SAML (Core Schema)" application only accepts the HTTP 200 (Success) status code to indicate a successful delete.
My application returns a 204 (No Content) status code for the DELETE method, in accordance with the RFC 7644 (SCIM Protocol) (emphasis mine):
In response to a successful DELETE, the server SHALL return a
successful HTTP status code 204 (No Content).
Since the SCIM developer documentation states that OneLogin "[...] supports SCIM 1.1 and SCIM 2.0", is the current approach correct? Should I change my status code to 200, and risk running into issues with providers that do correctly implement the SCIM 2.0 protocol?
You can use SUSPEND on delete instead of DELETE on delete in OneLogin SCIM App Provisioning Menu.
Related
I'm looking to implement a plugin using OpenSAML for a 3rd party application that will enable the application to be treated as a SAML Service Provider, so that I can integrate it into AWS SSO.
The following image describes the SAML authentication process when the Service Provider (SP) and Identity Provider (IdP) use HTTP Artifact binding (taken from here):
After the initial authentication, the SP returns the protected resource to the user. My question relates to how subsequent requests for protected resources are processed.
With OIDC, the browser would receive a token and this would be sent to the SP for subsequent requests. The SP can inspect the token and confirm its integrity (assuming it is signed) and validity, without needing to make further calls to the IdP to re-authenticate the end-user.
With SAML, how do I achieve the same effect? How do I not have to make repeated calls to the IdP to check identity?
I suppose I could use a session, but I don't understand how I might ensure that such information is not tampered with within the client (i.e. how does the SP not have to rely on information provided by the client?). Does SAML have some sort of concept of a token that is safe for the user to store (the HTTP Artifact binding explicitly restricts the user from seeing the response from the IdP)?
What happens after the last step is not defined in the spec. You could say it's formally outside of SAML protocol. Even the last protocol-formalized step of SP supplying the resource is essentially a "do it yourself":
Section 3.4.5 (HTTP-Redirect binding):
Upon receiving the SAML response, the SAML requester returns an
arbitrary HTTP response to the user agent
Section 3.5 (HTTP-POST binding):
Upon receiving the SAML response, the SAML requester returns an
arbitrary HTTP response to the user agent
Section 3.6 (HTTP-Artifact binding):
[you can probably guess by now]
Most SPs will drop one or more cookies on the client during that last step. One of those cookies will contain a session ID or a more generic pointer that can be used to locate a session when sent back to SP. Subsequent resource "authorization" requests to SP will proceed by having the SP consult this server-side session. The session will usually hold the (authenticated) security context for this user/client.
For example, Shibboleth (built on top of OpenSAML) does so. The content of the cookie is up to the SP. It's arguable that token-based auth via e.g. local storage is more secure vs a cookie. There are pros/cons to both options and many factors specific to use case/context/technology stack impact the evaluation of risk and associated threat model.
Note: AWS SSO does not support the Artifact binding.
I need help understanding my options for implementing a session status check. My goal is to support near real-time browser page redirection upon the termination of the session.
OIDC session management specification describes a way to check the session status with iFrames:
http://openid.net/specs/openid-connect-session-1_0.html#RPiframe
I'm not using Identity Server, but they have a nice write-up: https://identityserver.github.io/Documentation/docsv2/advanced/signout-session.html.
I see one main roadblock to doing that with ADFS though: My .../adfs/.well-known/openid-configuration page does not include a check_session_iframe endpoint. I cannot find information about the check_session_iframe in ADFS and what configuration controls its existence.
Can someone explain what I may be missing, or if there is another route I can investigate?
Context:
ADFS 3.0 is setup for front channel logout per this recent MS article (https://learn.microsoft.com/en-us/windows-server/identity/ad-fs/development/ad-fs-logout-openid-connect).
My App uses the OWIN nuget package to connect to ADFS
This wasn't feasible, so I had to change my strategy. The app just checks whether or not the app session is current, as opposed to the ADFS session.
I downloaded OKTA default test suite from, http://developer.okta.com/standards/SCIM/SCIMFiles/Okta-SCIM-20-SPEC-Test.json. I uploaded this to Runscope and tried to execute tests (I am referring to line number 782 in this json file.)
I noticed that “Required Test: Create Okta user with realisitic values” test case in OKTA SCIM default test which is a POST request to Create user resource (“Required Test: Create Okta user with realisitic values” POST {{SCIMBaseURL}}/Users) does not have Content-Type (In Line 782 in attached json file).
Is this intended or it's a bug?
When the “Content-Type” is not presented in the request, our SCIM Api returns Http Status Code 415.
I suggest setting up at template SCIM app in an Okta developer edition org and see what it sends as a Content-Type header, then modify your Runscope tests to use that header.
I also recommend that you open a ticket with developers#okta.com so you can get more personalized help on your integration.
we are developing a web application which offers multiple login mechanisms such as LDAP, Kerberos, SAP Logon Ticket as well as SAML.
For this we use the Spring Security Framework which works (mostly) fantastic!
A few months ago we added SAML support to our application and tested this with an external IdP (SSOcircle). We also worked closely with CEO of SSOcircle to get us up and running.
Everything worked just fine and we thought we could enroll SAML with our first real life customer.
So we setup a test server (SP) on a linux machine, and configured our part (we used this doc: http://docs.spring.io/spring-security-saml/docs/current/reference/html/chapter-idp-guide.html) and waited for our customer to do their part.
But when they tried to SSO into our application (they use ADFS), we ran into an issue.
Because right now, we get one out of two error messages. Either this one
Authentication request failed:
org.springframework.security.core.userdetails.UsernameNotFoundException:
Empty username not allowed!
or this one
Error validating SAML message org.opensaml.common.SAMLException:
NameID element must be present as part of the Subject in the Response
message, please enable it in the IDP configuration
During the troubleshooting I came across these other threads here on StackOverflow:
SAMLException: NameID element must be present as part of the Subject in the Response message, please enable it in the IDP configuration
Configuring ADFS 3.0 / SAML 2.0 to work with Spring Security for SSO integration
NameID element must be present as part of the Subject
The odd thing is, that the second error message (regarding the nameid) element comes up only if we change the adfs claim rule from "Outgoing claim type" to "Pass Through claim type".
Right now, I have no idea where to continue my troubleshooting. Any ideas or thoughts on this issue?
Best regards
René
EDIT1: I attatched a link to the debug logfile and our saml security config
EDIT2: Does someone know if there is a way to specify a timezone which SAML should use? Right now, Zulu time seems to be the time zone used although our OS is configured to use CET/CEST. Therefore we had to use responseSkew parameters for login/logout.
EDIT3: Debug & Config removed because we solved the problem
Okay, we solved the problem.
During a live debugging we noticed that NameID was not send as a SAML assertion attribute key/value pair but as a "standalone" key/value pair in the SAML assertion "header".
So we modified our code to cover both possible positions within the SAML assertion and now it works just fine. :D
For a mobile application (Cordova & AngularJS), I use Azure Mobile Services with Web Api.
I am currently experimenting with different OAuth implementations to see which one fits my needs the most.
Tried OAuth from ngCordova, OAuth.io, WAMS server flow and Auth0 with WAMS delegation.
I also came across the option using the "JsonWebToken DelegationHandler for WebAPI". With this approach, I should use the "System.Web.Http.Authorize" attribute. When I debug the JsonWebTokenValidationHandler, everything looks good (IsAuthenticated is true etc.), but at the end, a 401 is being returned.
I guess, WAMS overwrites the user principal. A look at the WAMS log reveals that "The 'Bearer' HTTP authentication scheme is not supported." As soon as there is such an authentication token present it seems to get rejected by Azure Mobile Services.
My first thought was, that I can probably remove a specific message handler but that doesn't seem to be the case. Does anyone have an idea to get this to work with WAMS?
There is another post with a question very similar to this one:
Azure mobile service using aad "The 'Bearer' HTTP authentication scheme is not supported" error
You can pass the application key in the header like so:
HttpClient.DefaultRequestHeaders.Add("X-ZUMO-APPLICATION", "<YOUR APP KEY>";
In that link, Matthew mentions details about how to user authentication and posts links on how to set it up properly which you may find valuable.