First of all I do not have any experience with SAML (version 2).
I was asked to investigate how we can make an existing site, which has a normal login page with a username and password page, ready for SSO with SAML.
There are some tools around which we can use in order to do this.
So I think it is not so difficult to implement the SSO part.
But however it is not clear to me how the authorization is managed.
The system (web site) is using authorization rights in order to determine if the user is able do access certain parts and if he does, the right type he has (view, create or edit).
These rights are assigned to each user by an administrator in the system itself.
When a user logs in the system by specifying his credentials (without SAML/SSO) his rights are also retrieved.
How is this done when a person logs into the site by using SSO?
Is there a mapping of the userId which is know by the IdP (Identity Provider) to the userId which is know by our system?
And is this send in the SAML response from the IdP?
Or is this done in another way?
Thanks in advance
SAML is mainly a authentication protocol but there are still many ways to solve this. SAML supports sending authorization infromation in AuthzDecisionStatement in the assertion.
Another alternative is to extend SAML using XACML which is a big framework for transferring Authz information.
However the support for these are limited in many SAML providers.
The simpler solution and probably the best in your case, if it is just one access right per user, is to send it as an attribute in the SAML assertion. This can usualy be mapped against for user properties.
Related
I am currently going through OneLogin's documentation.
There is one point that remains unclear to me.
I think I understand the main differences between SAML and OIDC.
However on the SAML description it seems that there is no authentication required from the end user.
Compared to the OIDC description, where a code is required from the end user.
This point only would make me lean toward SAML as it is "frictionless".
My questions are -knowing that I want to integrate with OneLogin-:
Is SAML "frictionless"? Can it be?
Is OIDC "frictionless"? Can it be?
If so, is it a specific OneLogin feature? (It seems that all the documentation that I found online mention authentication with the IdP)
Thank you for your help!
The article states:
"The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider."
So the user has to authenticate if no existing browser session.
The article is around SSO i.e. if you have already logged into an IDP with SAML and you access another application on that same IDP, you won't have to login again.
OIDC has the same approach.
OIDC can be "frictionless" if you use the Resource Owner Password flow where you pass the user name and password under the hood. The user does not have to authenticate.
But it's deprecated in OAuth 2.1 as it's not secure.
So, when management tells us our website needs to "support SSO through SAML 2.0", with no additional details, what are they thinking?
What will our customers expect?
Note - The is not an open website, where everyone can join. To log in you need to be a configured user in the system. The customer's admins need to create an account in our system for each user.
So we aren't going to let just anyone who has an account with an IdP in to our website. We'll have to have some mechanism for mapping a SAML identity to our users.
How would our customers expect that to work?
Based on hints in your question, I am going to presume that you will be acting as a service provider.
To be what I would call a "good" service provider, I would expect the following:
You sign your AuthnRequests.
You provide a metadata endpoint that is kept up to date with your SP metadata to include current public keys for encrypting attributes (if necessary) to be sent to you as well as validating your AuthnRequest signatures.
You support dynamic consumption of my identity provider's metadata endpoint to keep your side of the connection up to date, especially with concern to my signing certificate.
You expose management of my identity provider configuration inside of your service provider mechanism to my IdP administrators through a web or API interface.
You either support a mechanism to automatically manage my users (like via SCIM or Graph or something else), or you support Just-In-Time provisioning based on an incoming assertion.
You allow me to decide my SAML Name ID format, and that format is per-tenant. As an example, I may want to use email address as the identifier, while another IdP may want to use sAMAccountName. e.g., john.doe#domain.com vs. johndoe.
You support Service-Provider-Initiated SSO. That means that the user shows up to partner1.yourdomain.com and get redirected for authentication to that partner's IdP, and that going to the location partner2.yourdomain.com would redirect to a different IdP.
As a service provider, you should make using your service easy and secure. By shifting to SAML, it allows you to get out of the business of password and user management because you get to put that back on the identity provider. It allows your users to not have to type in a password (or more, if you're doing MFA) to use your service, removing friction caused by security. It allows you to put the onus of authenticating the user back on the organization that owns the identity.
Your customers would expect that if they have an application that uses the SAML 2.0 client-side stack then when the application sends an AuthnRequest, they will see a login page on your site and once authenticated, the application will receive a set of assertions (claims) from your IDP via an AuthnResponse.
One of these assertions is NameID. This is the "primary key" between their system and yours. Normally this is UPN or email.
This mapping is outside of the SAML spec. There needs to be some kind of "on-boarding" for the customers.
Our customer is using Okta and is asking us to SAML-enable our app so they can access it using idnetities in Okta.
We plan to use OpenSAML to do it. So far so good.
But usually, our app has access to identities (list of users, groups/members) coming from an on-prem LDAP or AD, for example. We normally use those identities to configure authorizations in our app (give permissions to certain users to access certain ressources). Using SAML only, I don't see how to access the whole list of users/groups. And from what I understand, it's not the goal of SAML to provide it.
How is this situation typically solved? Should we try to sync the identities between Okta and our app? Is it what is called provisioning? There is Okta API, SCIM, JIT, ... Or maybe we should take a totally different approach?
Thank you!
The typical way to handle authorization in SAML is to use a SAML assertion to determine the authorization that a user should have. Which assertion is used and how it is will depend on your authorization model.
Note that using assertions will push the responsibility for determining authorization onto the administrator of the SAML Identity Provider, it will be up to them to decide who has access to what.
The ideal situation for supporting "enterprise federation" is to support SSO and Provisioning. SAML or OIDC for SSO and SCIM for provisioning.
If your software doesn't depend on an up-to-date list of users, supporting just SAML with "JIT" might be sufficient. SAML with "JIT" or "Just In Time" provisioning just means that your SAML Service Provider implementation would add users that it hasn't seen before.
What I know so far is, to make any application SSO enabled, there must be an Identity provider taking part in the SSO game. So there is direct dependency on IDP as the SP need to "know" who the IDP is. Can SP have a common saml communication mechanism which can work with any IDP that my customer is using ? Or I need to build different saml communicator based on the customer supported IDP ?
Reason: One of our company customer is using Okta for its employees and want us to make our application Okta enabled so that its employees need not to remember credentials on our site anymore. That's fine. Now, if any other customer comes with some other IDP (PingOne for example), do we need to work again to make it that xyz IDP enabled ? or our existing implementation will work same way by just adding that IDPs url ? Let me know if I am missing any big picture or key concept here.
P.S. Our application is on .NET platform.
Unfortunately you will need to create a new association if a user want to use a new IDP.
There is a good reason for this. You need to be say that you trust the IDP. The IDP is the one that vouches that the user is who they say they are. So you have to ensure that you trust it to authenticate users for you system.
What you could do is to allow for the customer to define its the IDP to be used, provided that the IDP is only allowed to authenticate that customers users.
If you want to do this I would recommend using some third party software.
I have a scenario where the client uses kerberos authentication (this cannot be changed) and, thus my WCF web service only has access to the WindowsIdentity object (System.Security.Prinicpal.WindowsIdentity). The WindowsIdentity object doesn't tell me much about the user (basically just the login name). What I need are specific claims about the user (e.g. email, etc.) so that I can map the AD user to one of my systems users.
I have set up a relying trust relationship with ADFS and from my server, using username and password, I am able to retrieve a SAML token and extract the claims I want (i.e. UserNameWSTrustBinding).
With that being said, it seems that given that I have a WindowsIdentity object in hand (ultimately provided by the ADFS system) I should be possible to ask ADFS to issue me a SAML token. That is, rather than specify the username/password I provide the WindowsIdentity.
I would greatly appreciate it if someone could point me in the right direction of how to accomplish this.
Thanks much!
Edit:
I have located the following Microsoft document showing the transformation of a kerberos ticket to a SAML token. So I know its possible, I just haven't yet figured out how to accomplish it.
https://msdn.microsoft.com/en-us/library/ff359114.aspx