Microsoft provides a variety of windows credential providers referred to as "security support provider" as part of microsoft windows, such as
・password (*1)
・smart card (certificates in window authentication) (*2)
・window hello, PIN (FIDO 2) (*3)
Kerberos is the primary method of authenticating users on Windows for interactive logon using passwords and network logon using Kerberos tickets.
domain user logon process
From using above (*1) or (*2) or (*3), I really want to know is there any simple method to issues (create) kerberos tickets?
I have also consulted microsoft API set about this model (domain user logon process), but there does not seem to be a API to issues (create) ticket kerberos.
The API I have referenced:
SSPI: https://learn.microsoft.com/en-us/windows/win32/api/sspi/
LsaLogonUser: https://learn.microsoft.com/en-us/windows/win32/api/ntsecapi/nf-ntsecapi-lsalogonuser
Please let me know. Thanks in advance!
Credential Providers are not SSPs; they are Credential Providers. They ferry the credential you're using from the inputs (keyboard, bio, smartcard) to the SSPs. They're not meant to do heavy lifting. The SSPs do the actual protocol work of authenticating to whatever service is your authority.
The image you reference is not technically accurate as that's the pre-Vista process. Everything on the left side of the image is out of date. The right side is still mostly correct.
Color commentary aside, Samson is correct. AD is the ticket creator and the only way you can get it to create a ticket is by requesting it after you've authenticated with a credential, and its for the named credential to a specific named service. The way you request the tickets is through the SSPI ACH and ISC functions. SSPs are the internal implementations of those functions.
LsaLogonUser will verify a credential and store the resultant ticket in a dedicated cache (separate from the default logged on session cache). Often you call CredUIPromptForWindowsCredentials to collect creds, and pass the buffer to LsaLogonUser or the ACH function.
Related
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.
I am designing the authentication system for a piece of software and need some guidance on how SASL and Kerberos services interact.
Here is the situation:
I have a client/server application that is itself pretty standard: only registered users can use perform actions. As an MVP I would typically implement a pretty standard solution:
Database stores username + salted hash of passord
Authentication attempt from client over HTTP includes username/password over TLS
Backend checks that username/password are valid and returns a bearer token that can be used for the duration of the session
In this case, however, there is a complicating factor. Some users of our system use Kerberos internally for user authentication for all internal services. As a feature, we would like to integrate our software with Kerberos so that they don't have to manage an additional set of users.
A more senior engineer recommended I look into SASL so that we might support several auth protocols simultaneously; standard customers can authenticate their users with the PLAIN method (over TLS), for instance, while other customers could limit authentication to only the GSSAPI method.
Up to this point, I have a clear idea of how things might be set up to achieve the desired goals. However, there is one more complicating factor. Some of the customers that want our system's auth to support Kerberos have other resources that our system will rely on (like HDFS) that also require authentication with Kerberos.
My understanding of Kerberos is this:
A client authenticates with Kerberos's ticket granting server
Upon successful authentication a TGT is returned that can be used for any future interaction with any Kerberos service in the system
Now to the point: How can I make all of these technologies work in harmony? What I want is:
- Client logs into my server
- My server authenticates client using customer's Kerberos system
- Client is given the OK
- Client asks for something from my server
- My server needs access to customer's HDFS, which requires Kerberos auth
- Server authenticates without asking the client to authenticate again
One possible solution I see to this is the following:
Make my server itself a Kerberos user
When the server needs to perform an action on HDFS, have it authenticate using its own credentials
There is a big downside to this, though: pretend the customer's Kerberos system has two realms: one with access to HDFS and one without. If users of both reals are allowed to use my system, but only one set can use HDFS, then I will need my own logic (and potentially objects in a DB) to determine who can perform actions that will require access to HDFS and who cannot.
Any pointers are going to be super helpful; in case it isn't obvious, I am quite new to all of this.
Thanks in advance!
It's not clear exactly what your question(s) are, but I'll do my best to address everything I think you're asking.
Firstly, I just want to clear this up:
Upon successful authentication a TGT is returned that can be used for
any future interaction with any Kerberos service in the system
That's not quite correct. The TGT enables the user to request service
tickets from the KDC for specific services. The service ticket is what
gives the user access to a specific service. The TGT is used to prove the
user's identity to the KDC when requesting a service ticket.
Client asks for something from my server - My server needs access to
customer's HDFS, which requires Kerberos auth - Server authenticates
without asking the client to authenticate again
This is a common enough problem and the Kerberos solution is called delegation. You should try to use Kerberos delegation in preference to coming up with your own solution. That said, how well supported it is depends on the technology stack you're using.
There are 2 kinds of delegation supported by Kerberos. The first kind is just called "delegation" and it works by sending the user's TGT to the service along with the service ticket. The service can then use the TGT to get new service tickets from the KDC on behalf of the user. The disadvantage of this approach is that once a service gets a user's TGT, it can effectively impersonate that user to any service that the user would be able to access. You might not want the service to have that level of freedom.
The second kind of delegation is called constrained delegation (also known as services4user or S4U). With this approach, the client doesn't send it's TGT to the service, but the service is allowed to ask the KDC for a service ticket to impersonate the user anyway. The services that can do this have to be whitelisted on the KDC, along with the services that they can request tickets for. This ultimately makes for a more secure approach because the service can't impersonate that user to just any service.
A more senior engineer recommended I look into SASL so that we might
support several auth protocols simultaneously; standard customers can
authenticate their users with the PLAIN method (over TLS), for
instance, while other customers could limit authentication to only the
GSSAPI method
Yes this is a good idea. Specifically, I'd recommend that you use the exact same session authentication mechanism for all users. The only difference for Kerberos users should be the way in which they get a session. You can set up a Kerberos-protected login URL that gets them a session without challenging them for credentials. Any user that hits this URL and doesn't have Kerberos credentials can just be redirected to a login page, which ultimately gets them the same session object (once they log in).
On the back end, the credential checking logic can use SASL to pass Kerberos users through to the KDC, and others through to your local authentication mechanism. This gives you a seamless fallback mechanism for situations when Kerberos doesn't work for the Kerberos users (which can happen easily enough due to things like clock skew etc.)
There is a big downside to this, though: pretend the customer's
Kerberos system has two realms: one with access to HDFS and one
without. If users of both reals are allowed to use my system, but only
one set can use HDFS, then I will need my own logic (and potentially
objects in a DB) to determine who can perform actions that will
require access to HDFS and who cannot.
This kind of thing is exactly the reason that you should use Kerberos delegation instead of coming up with your own custom solution. With Kerberos delegation, the KDC administrator control who can access what. If your service tries to impersonate a user to HDFS, and they are not allowed to access it, that authentication step will just fail and everything will be ok.
If you try to shadow the KDC's authorization rules in your own application, sooner or later they'll get out of sync and bad things will happen.
I am developing an SAP Enterprise Service that allows the user to logon via an X.509 certificate. Internally, there is a mapping in the customizing between the external user ID and the internal ERP user name.
In my logic I need to determine whether the user has logged on via basic authentication (user/password, technically still possible) or via the certificate. I think I can manage it by calling a kernel routine (LOGIN_INFO).
However, how do I obtain details about the certificate the user used to logon? I want to check if the certificate was issued by a certain certification authority.
Any experience here?
Take a look at CL_HTTP_SECURITY_SESSION* classes. In fact, the class CL_HTTP_SECURITY_SESSION_ADMIN has a method that gives us from table SECURITY_CONTEXT the logon method of the session.
DATA: lt_sessions TYPE security_context_tab,
ls_session LIKE LINE OF lt_sessions.
lt_sessions = cl_http_security_session_admin=>list_security_session_contexts( ).
There is a field AUTHNMETHODS, which stores the auth method in a numerical format: ie 8000 is basic authentication.
There is a method in the same class: DECOMPOSE_AUTHNMETHODS_FIELD, which should help you to get the auth method.
Hope this helps, i've never implemented this on a Enterprise Service,so i'm not sure this class could be helpful, but on some http straightforward connections to the SICF it works well.
Regards
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.
I'm working in a company that uses Microsoft Active Directory. We have an external company that provides an internal web site for a particular project. The site is external to the company. The sign on to the external site is the user's company email.
We want a system whereby the external site calls into the organisation's AD to verify if an email address is still valid or if the user has left the company. It should be a simple call to Active Directory Federation Services or some sort of SAML interface. The call would be a simple request 'here's an email, is it valid?' and the response is either yes or no.
Our IT department are trying to tell us that it's too complicated and I don't believe them. I think they just don't want to do it.
Does anyone know how easy it would be to create a simple system that would allow an external service to do the query outlined above.
ADFS is not meant to do that. However, a by-product of using it, would be the validation you are looking for.
The first question would be: what is the authentication method of your app? e-mail and what else? password? which password? Does the app keep a database of users/passwords?
ADFS works as an "identity provider" and would authenticate users in AD. ADFS would supply a security token that can be consumed by your app. Part of the information sent in the security token could very well be (and often is) the user e-mail address (that's why it is a "by-product").
For this to work, the app would have to be changed to accept security tokens (SAML tokens to be specific). If the app is .NET based, then it is done usually with WIF (WIndows Identity Foundation).
This approach would be the most elegant and secure because the app would delegate the responsibility of authenticating users to the authority of these employees: AD.
App --trusts--> ADFS --authenticates--> AD
Setting up ADFS, etc is not super-difficult, but it is not super-simple either, and might not be worth just for this app. There are other lighter weight alternatives: open source products like Identity Server, or products like the one I work on.
Now, if all you need to do is to validate that the e-mail actually exists, the best is to send a verification message to that address with some unique code that the user sends back. This is the same approach used in many common web apps.
Agree with everything #Eugenio said - have same questions about authentication.
But if you simply want code to query an user's email address in AD, you use the AD API's.