We are using itfoxtec-identity-saml2 library to integrate saml in our .Net web API application.
We are passing a couple of custom attributes in relayState (ex. returnUrl, redirectionParams etc.) to make use of them once we get the relayState back from SP.
One of the service providers is not able to return relayState with multiple parameters because of the "&" separator.
Is it possible to include these custom attributes in Saml2AuthnRequest object and get the same attributes back in Saml2AuthnResponse or is relayState the only way to send and receive the custom dynamic parameters?
Is it possible to include these custom attributes in Saml2AuthnRequest object and get the same attributes back in Saml2AuthnResponse
A SAML2 authentication request can contain various custom extensions to carry extra data, flags, etc. However, anything that you would include in there would be custom, and the service provider implementation must be able to support and recognize it. It's completely non-standard and would not scale.
is relayState the only way to send and receive the custom dynamic parameters?
Yes, it is. You might want to encode the final value in such a way that could be included in the relay-state parameter as a single value.
Related
Titlte says it all I think.
I have encountered both and don't know which one I should use between $_SESSION['Auth'] and $this->Authentication->getIdentity(). Is one safer than the other ?
Thank you,
Simon
With CakePHP you should always use the abstracted APIs to access any superglobal data like $_POST, $_COOKIE, $_SESSION, etc..
This is advised for a multitude of reasons that depend on the specific situation, but generally it kinda touches the principle of dependency inversion, and decoupling in general, eg. your code should depend on abstractions, not concretes, then for example implementations can change without breaking your application. And while the session object, the request object, or the authentication component aren't interfaces, they still abstract the access to the underlying data (the concrete so to speak).
Something where the need for this would apply generally, would be testing, except for the CakePHP session object, which must write the data to the $_SESSION superglobal internally, other superglobals like $_GET, $_POST, $_COOKIE, etc. are not being populated if you use the API provided by CakePHP, instead the data is written into the request object, which exposes the data via its own API. So if you were for example to access $_POST directly in your code, and then pass POST data in a test like $this->post('/url', $postData), your code wouldn't see the data, as it would directly land in the request object instead of the $_POST superglobal.
As far as the authentication example specifically goes, the authentication middleware could have obtained the identity with data from who knows where, the session, cookies, tokens, etc., and likewise it could persist the identity anywhere, the session, cookies, etc, the inner layers of your application shouldn't have to care about such implementation details, they obtain the identity via the component, or from the request object, and that's it, they don't need to know anything else, then you can easily change how authentication is handled without breaking the rest of your application.
When implementing IS4, we want to have a couple of extra fields on the /Account/Login form (we're building off of the Quickstart UI). The data provided by these fields (location info - 1) building and 2) station within the building) needs to be accessible when IProfileService is called as they are pieces of information used to determine the claims to be provided in GetProfileDataAsync(). We tried storing the data in HttpContext.Items, but that data is lost since there is a redirect that occurs before IProfileService is called.
Do you have any recommendations for how to pass this data back to IProfileService?
One of the extension methods on the HttpContext, SignInAsync, allows you to pass in any extra login related claims. If you add ‘building’ and ‘building_station’ as claims when you call SignInAsync from the AccountController, you should be able to access it through the HttpContext.
To do this you need to add the HttpContextAccessor to the IProfileService implementation through dependency injection, and once you get the HttpContext from it you should be be able to locate the appropriate claims in HttpContext.User.
I am building a jsonapi for my website, and while looking at various frontend components I came across
https://github.com/dixieio/redux-json-api/tree/master/docs
Which seems to resolve the endpoint URL directly from the resource type
It is part of the spec/recommendations to have the endpoint resolved exactl by the resource type ? I remember reading comment explaining there isn't an actual type naming convention.
My API has several endpoints for the registration of different types of user
/registration/admin
/registration/customer
etc.
Those endpoint have different business logic associated, but they all return a user type object.
Is this a bad design to have several endpoints returning the same resource type ?
Should I make changes in my code to introduce additional type like registration/user ?
Or should I submit a patch to the library so it accepts custom endpoint URLs ?
I can't address specifically the framework you're using, but you have complete freedom to choose what your HTTP resources represent. If, for example, customers can be corporate and have associated invoices and sales history, but admins are only ever individuals and cannot transact, you could make a strong case for keeping the resources seperate.
One thing you should try to avoid is allowing limitations of software dictate your URI structure. If I were creating this API, and had decided that customers and admins were different types of object, I would have the registration form resources live at /admins/new and /customers/new which would make POST requests to the collection resources at /admins and /customers. I would not have a /registration* at all.
To address your invividual questions:
I don't understand what you mean by ‘returning a resource type’ — are you talking about the representations returned in the responses, or how the back-end functions are creating and returning instances of a class?
I would not add an additional super-type for all kinds of user. Either have one collection per type, or one type for all.
If after considering all of the above and choosing URIs you want, your software cannot handle the structure you have chosen, there are three options:
i) choose more capable software
ii) create a mapping between the incoming URI and the URI handed to your software. Apache mod_rewrite can do this for you
iii) as you suggest, make the software you are already using more capable
Choose the easiest option.
I've got AngularJS and Web.API WAAD authentication up and running. For client side I use great library ADAL.JS. For backend I use Microsoft.Owin.Security.OAuth. This part went quite smooth.
Now I want to implement authorization based on roles (which will be mapped to WAAD groups). Groups are not included in authentication token so I must ask Azure Graph API for them. I saw various ways to do it, using custom claims providers, adding web services to project, etc. Some examples already providing mapping between groups and roles to use in [Authorize] attribute.
But what is just the simplest example of how to get a list of group ids/names from WAAD providing User ID or username, when I'm already authenticated?
Also, is there any way to get this data in JS to use in Angular frontend, or should I create an API service which Angular should call for roles info?
In the non-JS case, the simplest way of getting groups in the token is by opting in. Download your application’s manifest, locate the “groupMembershipClaims” entry, change its value to “SecurityGroup” or “All”, upload back the manifest.
However note that this won't work for your scenario, because it uses the implicit grant - here the token is returned in an URI fragment, hence a big token would risk blowing past the URL length limits of the browser.
You can always request groups to the Graph and make it available to your frontend via custom action on your API, but from what you wrote you are already familiar with that. Let me discuss the matter here - if there's a simpler route to make this work in SPAs, I'll get back to this thread.
HTH
V.
Update: I verified and in the implicit grant case you will receive groups always via the overage claim. Please refer to https://github.com/AzureADSamples/WebApp-GroupClaims-DotNet/tree/master/WebApp-GroupClaims-DotNet - it will show you how to process the overage claim to retrieve groups. All you need to do is apply the same guidance to a web API instead, and if you need to make the info available to the client expose one or more actions doing so.
I'm trying different ways of implement multi tenant AppEngine web RESTful interface.
One of them is to use part of the URL as the tenant name.
The problem is that I'm using Jersey as JAX-RS implementation for RESTful interface and I would like a url such as /tenant1/res1 to first be parsed by something that will take the /tenant1 part, set the namespace to tenant1 and then pass the rest of the URL to Jerseys' servlet for regular handling.
The something maybe either ServletFilter or Servlet or something I can't think of.
How can I implement such thing?
What are the possible problems of such implementation?
Thank you,
Ido.
I do exactly that but using Restlet. The namespace uniquely identifies the customer that a user belongs to.
The first URL fragment contains the namespace. I verify the namespace in a RESTLET authenticator (basically a filter) and when the authenticated user does not belong to the given namespace/customer I refuse to proceed.
I use the primary key of the customer as the namespace. This has the added advantage that a valid namespace/customer can be easily (mem-)cached, and I refuse any calls containing invalid namespaces.
Very happy with this setup and no problems encountered.