Find out detailed information about X.509 certificate the ERP user logged on with - certificate

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

Related

Getting SAML token with claims from ADFS using WindowsIdentity

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

How to determine authorization rights after a login via SAML SSO

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.

Need to SSO to a vendor using SAML, not sure what path to take

I'm trying to set up a single-sign-on solution to a 3rd party site. They currently don't have anything set up on their end yet, but they want to use SAML. They instructed us to "provide them a sample of a standard SAML2.0 message", and sent over a certificate. Kind of asking me to show them a key and they'll build a lock to put it in.
I need some direction on what to actually set up for this. The vendor has cryptically stated that they are using these parts of the SAML message: ds:Signature, saml:Conditions, samlNameId. I've put together a C# console app that can produce a Saml2SecurityToken using their certificate and a given Name Identifier, and set a timeframe for the condition. I think this is what they need from me.
We do have ADFS however. I've used it to authenticate users accessing internal sites, so I have a little experience with it. I'm overwhelmed by the information for ADFS though, and can't grasp what to set up for this kind of situation - I don't know how to translate the vendor & I's relationship into ADFS terminology.
Can someone explain who I am and who they are in ADFS terms? I think all the pieces for setting this relationship are right there, but I'm just getting swamped by the volumes of information on every page about ADFS.
On your ADFS site, navigate to:
https://your server/federationmetadata/2007-06/federationmetadata.xml.
Save this file, send to the vendor. This is the metadata. It describes the SAML profiles, the certificates, the public keys etc. You don't need to send them any actual certificates.
Ask the vendor for their metadata. Import this into ADFS as a Claims Provider Trust.
Configure your application via WIF to use ADFS.
When the user navigates to the application, the user will be redirected to ADFS. They will get the Home Realm Discovery screen and select either the 3rd party vendor or ADFS to authenticate and then they will get access to the application.
If ADFS is the source of authentication ADFS is the IP, the vendor is the service provider (RP). And obviously vice versa.

How to get ADFS to respond to a query about an user's email address

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.

How to use the metadata file (saml2)

I am working on a project that needs to be integrating SAML2.0. I was thrown into this project suddenly, i need to make it work.
Here is the background: We have created the files and wanted Client Company to integrate using SAML2 to get to our web site. We have sent them the meta datafile.
Now the client company had sent their metadata file. I dont know how and what to do with that file. Any help will be appreciated.
ASP.NET, Framework 4.0
The metadata file basically provides you information of your client. Such as entityID, credential, and so on. If it is an IdP then it also contain couple URLs so that you know where to send different request, e.g. login request, attribute query request. You need to give this metadata to your SAML component so that it know which client it should talk to.
Another main purpose is to establish a trust relationship between SP and IdP.
It's kind of old question but I would like to add some additional information and resources for .NET.
SAML Metadata is used to exchange configuration information between Service Provider and Identity Provider and vice versa. The information can include:
Binging location
Organization name
Contact Person
Single Sign On Url
Single Logout Url
The Metadata can be signed and encrypted so that the information is sent securely. The other side may need the corresponding public key to validate and decrypt it and then can be used to understand and establish the connection with the SP or IdP.
You can see some more info at the following blog posts:
http://samlcomponent.net/constructing-saml-metadata-xml-for-single-sign-on-idp/
http://samlcomponent.net/how-to-create-saml-metadata-xml-for-service-provider/
Security Assertion Markup Language (SAML) is a standard for logging users into applications based on their sessions in another context. This single sign-on (SSO) login standard has significant advantages over logging in using a username/password:
1.No need to type in credentials
2.No need to remember and renew passwords
3.No weak passwords
It is easy to manage all applications in one tree using SAML SSO login.
How actually SAML works:
The user accesses the remote application using a link on an intranet, a bookmark, or similar and the application loads.
The application identifies the user’s origin (by application subdomain, user IP address, or similar) and redirects the user back to the identity provider, asking for authentication. This is the authentication request.
The user either has an existing active browser session with the identity provider or establishes one by logging into the identity provider.
The identity provider builds the authentication response in the form of an XML-document containing the user’s username or email address, signs it using an X.509 certificate, and posts this information to the service provider.
The service provider, which already knows the identity provider and has a certificate fingerprint, retrieves the authentication response and validates it using the certificate fingerprint.
The identity of the user is established and the user is provided with app access.
Take a look at the metadata SAML 2.0 specification to check what elements must be read by your implementation.
If you are looking for a SAML2 .Net Tookit, take a look to this thread of stackoverflow
Also take a look on SAML open source implementations to learn how others resolved this problem before:
SimpleSAMLphp (PHP implementation Idp/SP). (Metadata parser)
Shibboleth IdP (Java) (opensaml2) / SP (C)
spring-security-saml: SP (Java) (metadata files)
Jboss (Java)
Metadata is nothing but the xml file containing all the information required by your SAML implementation to talk with host. you can extract information from this meta to get the desired information required. Like public/private keys.
I hope you are also using certificate to talk with host on secure manner.
This key is required for handshaking with unknown host system.